Tk Source Code

See attached pics.

Did something change in tksvg?

The basic clam derived themes seem to display their progress bars without issue,
so I am suspecting svg.

And awbreezedark is derived from the 'default' theme.

Merged branch bug-8bee4b2009-alt to the main (8.7) branch.

A few notes about the testing:

- Github Actions (the CI runner) is happy with branch bug-8bee4b2009-alt.

- It is not happy, on Linux only, with branch bug-8bee4b2009 (failure of progressbar-3.3, that I cannot reproduce on my Debian 10 here). Anyway, this solution is not as good as branch bug-8bee4b2009-alt.

Does anyone want to test this branch bug-8bee4b2009-alt more before I merge?

In branch [https://core.tcl-lang.org/tk/timeline?r=bug-8bee4b2009-alt|bug-8bee4b2009-alt] I'm proposing a better solution.

Instead of the standard Text element also used by other widgets, the progressbar widget now uses a 'collapsing text' (cText) element, that only differs from the Text element by its behaviour when the text to display is empty. In this case the dimensions of the cText element become 0,0.

Now, when configuring the progressbar with -text "" there is no difference with before TIP #442 was introduced. And (as previously) when configuring the progressbar with -text "some text", the progressbar height adjusts to be at least as tall as the font height.

Testing appreciated, thanks!

I have committed a new test progressbar-3.3 demonstrating this problem.

Also, I have proposed a workaround making the test pass without new failures in the test suite. It consists in having a default font for progressbars of a very small size. Maybe this workaround can qualify as a fix.

See branch [https://core.tcl-lang.org/tk/timeline?r=bug-8bee4b2009|bug-8bee4b2009].

Is it possible for the progressbar to set the font size ahead of time?
To 1 as the default, then if text is specified, to the progress bar height - 2?

Brad, I understand what you're saying about the styling of the images. Thanks for getting me back on track :-) !

What is happening is that in 8.7 the horizontal progressbar is capable of displaying some text since TIP#442 (Feb-2016). The layout of the progressbar is:
<verbatim>
TTK_BEGIN_LAYOUT(HorizontalProgressbarLayout)
    TTK_GROUP("Horizontal.Progressbar.trough", TTK_FILL_BOTH,
	TTK_NODE("Horizontal.Progressbar.pbar", TTK_PACK_LEFT|TTK_FILL_Y)
	TTK_NODE("Horizontal.Progressbar.text", TTK_PACK_LEFT))
TTK_END_LAYOUT
</verbatim>

Whith these TTK_PACK_* flags, when measuring the size the progressbar should have, ttk (in <code>Ttk_NodeListSize()</code>) sets the height of the progressbar to be the max between the pbar element height and the text element height.

The height of the pbar element is the height of the image it displays.

The height of the text element is the height of the font associated to the text (this is specified by the <code>-font</code> option of the <code>ttk::progressbar</code>).

When the height of the text is larger than the height of the image in the pbar element, ttk tiles the image so that it fits the height of the progressbar. This is what happens with your test script, and it is fine!

I think (but didn't verify it) that it doesn't happen with some themes because the image they display in the pbar has a larger height than the height of the default font (<code>TkDefaultFont</code>).

You seem to expect the height of the progressbar to be the height of the image it displays, but this would be expected only if the <code>-text</code> option is <code>""</code>. In the opposite case, the text would be truncated horizontally at the height of the pbar image which wouldn't look OK.

As already mentioned, we can work around the problem and obtain the desired effect by specifying a very small font: <code>.pb configure -font {Arial 1}</code> for instance.

So far what is happening is now clear I think.

Now, what should happen instead of the current behavior? Should ttk decide the height of the text element is zero whenever <code>-text</code> is <code>""</code>? If so, we should perhaps be careful and do this only for the progressbar widget. The following patch (which is not specific to the progresbar widget) triggers failures in the test suite as I would expect:

<verbatim>
Index: generic/ttk/ttkLabel.c
==================================================================
--- generic/ttk/ttkLabel.c
+++ generic/ttk/ttkLabel.c
@@ -81,10 +81,13 @@

     text->textLayout = Tk_ComputeTextLayout(
            text->tkfont, string, -1/*numChars*/, wrapLength, justify,
            0/*flags*/, &text->width, &text->height);

+    if (*string == '\0') {
+       return 0;
+    }
     return 1;
 }

 /*
  * TextReqWidth -- compute the requested width of a text element.
</verbatim>

Due to the nature of ttk, doing this for the progressbar widget only is not easy at all.

Any other suggestions?

Dear Francois, dear Brad,

thank you for looking into this.

To check the issue, I have diffed tksvg trunk and tk8.7a5 svg files.

The only difference is, that "Tcl_GetStringFromObj" is called with an int length pointer and not with a size_t length pointer.

The last release of tksvg 0.7 has a bugfix as difference.

Thank you,
Harald

Now you are definitely going in the wrong direction.
The styling of the images is immaterial. 
The border was supposed to be there.

The presumption that there is some height X, and the images are
supposed to be designed to fill that X is incorrect.

I don't know why the horizontal progress bar has -sticky ns turned on.
I tried turning it off, but it had no effect (or I did something wrong).
But, even if -sticky ns were removed, and the image no longer tiled, 
the height would still be incorrect.

I will attach the rounded line images from the breeze/arc themes.

Well... things get complicated when looking in the wrong direction as I did today.

I thought I had correctly saved the png image to be full blue, but it had a border, so I was seeing the same effect as with the svg image.

I'm back pointing at svg in fact. A few things:

  *  The svg data you are providing as an example has stroke parameters in the <rect > element. This means the image is not completely blue as one could expect. It has, well, a stroke around it, which is colored #222222 (grey) , and is 0.7 in width. This means that when Tk is tiling this image to fill the parcel this stroke is visible. I would expect the svg image be without stroke (stroke:none in the svg code) for a progressbar. If you open the svg image with Inkscape for instance you will see the stroke.

  *  When the stroke is removed, the issue is however still not fixed. Example:

<verbatim>
package require Tk
set imga [image create photo -file {C:\Users\francois\Desktop\bradimageNostroke.svg} -format {svg -scale 20}]
label .l -image $imga -borderwidth 0 -highlightthickness 0 -padx 0 -pady 0 -bg red
pack .l
</verbatim>

(bradimageNostroke.svg being a file with the svg code you provided, changed with stroke:none instead of stroke:#222222)

No ttk here, just an svg image rendered on a label widget, with no border or padding. This example shows that what we're seeing around the blue image is the label background. And this after all points to an issue in computing the dimensions of the svg image I think since it does not happen with a png image (this time I'm sure of that - try it).

More findings on Windows:

  *  KO : winnative  default  classic  
  *  OK : clam  vista  xpnative
  *  Definitely not a tksvg issue, it also happens when directly using a png image from the disk instead of an svg image

I think there may be an issue with tiling the image in the parcel in ttk somewhere in the chain ImageElementDraw() -> Ttk_Tile() -> Ttk_Stripe() -> Ttk_Fill(). This all happens [https://core.tcl-lang.org/tk/artifact/d5ee5e3b?ln=178,337|here].

Another workaround, apart from changing the size of the text as already said below, is to use <code>-border {2 2}</code> as an option in the <code>::ttk::style element create</code> incantation (the height of the progressbar is then the height of the TkDefaultFont font).

A workaround is to configure the progressbar to display a very small text:

<code>.pb conf -font {Arial 1}</code>

When removing [https://core.tcl-lang.org/tk/artifact/854f26e5?ln=564|this line] (i.e. don't take TIP #442 into account in the rendering), there is no problem anymore.

Now tksvg is ruled out.

When removing [https://core.tcl-lang.org/tk/artifact/854f26e5?ln=564|this line (i.e. don't take TIP #442 into account in the rendering), there is no problem anymore.

Now tksvg is ruled out.

Can be reproduced on Windows if in the test script

<code>ttk::style theme use default</code>

is added so that the same theme is used as on x11.

Ok, so at this stage we don't have a clue yet about whether the issue is in Tk (8.6 vs 8.7) or in the svg code (tksvg vs svg code embedded in 8.7), right? We should find this out first I think.

This is with 8.6.11, and a recent download of tksvg:

bll-g7:bll$ tclsh pbar-test.tcl
A: 12
B: 14 
OK

The -scale is there just to make the issue more obvious.
It fails with -scale 1.0 also, and the rendering is not correct.

bll-g7:bll$ $HOME/t/localD/bin/tclsh8.7 pbar-test.tcl
A: 14
B: 19 
FAIL

Now that we have a script to reproduce I could see the issue on X11 and investigate a bit.

This rendering (with the horizontal line) is the same since [40ae80f8] which is the introduction of TIP #507 in trunk. This means in particular that this was here already in Tk 8.7.a3.

I can also observe that if I remove the <code>-scale 0.8</code> option from the <code>image create</code> command the rendering is correct.

What I didn't try yet is to use the tksvg vanilla package instead of the built-in svg support from TIP #507. My understanding is that it is OK with tksvg, can you confirm this perhaps?

Sheesh.  I just now figured out what was happening.

More images are not helpful to me.
A script I can use to reproduce the issue might be helpful, depending on what other factors contribute.
Maybe more capable Tk developers can puzzle this out.

X11, yes.  I expect the same issue would appear on Windows and MacOS, though
I have not tested there (and MacOS people rarely use alternate themes).

I should repeat, that this only seems to happen with SVG images.
The gif based themes display ok.

What platform? From the images I guess it's X11. Correct?

The height issue can be clearly seen in the attached "scaleddemo" image.
The height of the progressbar shoould be the same as the width of the 
vertical progressbar.

In both the default size and the smaller size in the picture, the height 
is set to 18, not 14 and 10 as it should be.

reqheight for the progressbar with 8.6.11 is 14.
reqheight for the progressbar with 8.7 is 18.
In both cases, the [image height ...] is 14.

Something in 8.7 is adding another 4 pixels to the horizontal progressbar
height.

Is there a demo script so a bisecting strategy can locate the regression?

We need hope for a fix quickly, or we have to move on with a release.

Another thought to research.
Did the -sticky setting change?  Or is honored now?

Attached a diff of generic/ttk/ttkProgress.c from 8.6.11 to 8.7.
There's a lot of code cleanup, but it looks like there were some additions.

Better title.

All .svg files associated with the various progressbar themes loaded fine.
Note that the same files are also used for the scrollbars, which work.

Thinking out loud...

- The themes that use gifs work properly (e.g. breeze, arc); the horizontal 
  progress bar's height is correct.
  This points to svg.
- The only item that is failing is the horizontal progress bar.  Other svg
  images are fine.
  This points to ttk.

Are my horizontal progress bar .svg files svg data?
But the code from the tksvg download works with 8.6.10 and 8.6.11,
and the changes are presumably present.

Nevertheless, I should check the progress bar and (if used) progress bar trough
files.

The master branch of tksvg works fine with 8.6.11.
It might not be svg.  Someone could have changed some ttk code.

Yes, there is the test, if data is not svg (to not load the whole data and discard it). But that is also in tksvg 0.7.

In tk8.7a5, there is a small additional race condition fix.
You may take the tksvg master branch to double-check, as this change is not released in tksvg jet.

Harald