Tk Source Code

View Ticket
Bounty program for improvements to Tcl and certain Tcl packages.
21:14 Ticket [8bee4b20] 8.7 : progress bar no longer displays properly with certain styles. status still Open with 3 other changes artifact: 55c1a722 user: bll
20:14 Ticket [8bee4b20]: 3 changes artifact: e68cd348 user: fvogel
07:45 Ticket [8bee4b20]: 4 changes artifact: dc94f39a user: oehhar
23:59 Add attachment png-slider.png to ticket [8bee4b20] artifact: 71806472 user: bll
23:59 Add attachment png-trough.png to ticket [8bee4b20] artifact: fe752bfe user: bll
23:59 Add attachment trough-rounded-line.svg to ticket [8bee4b20] artifact: da83f5f6 user: bll
23:58 Add attachment rounded-line.svg to ticket [8bee4b20] artifact: 0e9d5fc2 user: bll
23:56 Ticket [8bee4b20] 8.7 : progress bar no longer displays properly with certain styles. status still Open with 3 other changes artifact: 19c0c44f user: bll
20:39 Ticket [8bee4b20]: 3 changes artifact: 5665191f user: fvogel
12:03 Ticket [8bee4b20]: 3 changes artifact: 6b3eebde user: fvogel
16:46 Ticket [8bee4b20]: 3 changes artifact: b69941d4 user: fvogel
16:37 Ticket [8bee4b20]: 3 changes artifact: b84de0f9 user: fvogel
16:36 Ticket [8bee4b20]: 3 changes artifact: 90f6d6d2 user: fvogel
16:04 Ticket [8bee4b20]: 3 changes artifact: 1caa868e user: fvogel
15:11 Ticket [8bee4b20]: 3 changes artifact: ffcf0efc user: fvogel
13:02 Ticket [8bee4b20]: 3 changes artifact: b7882d91 user: bll
11:24 Ticket [8bee4b20]: 3 changes artifact: 18c2e814 user: fvogel
16:58 Add attachment pbar-test.tcl to ticket [8bee4b20] artifact: 14c89d2c user: bll
16:58 Add attachment pbar-test.tcl to ticket [8bee4b20] artifact: 33aabe9a user: bll
16:57 Ticket [8bee4b20] 8.7 : progress bar no longer displays properly with certain styles. status still Open with 3 other changes artifact: 00c8a019 user: bll
16:39 Ticket [8bee4b20]: 3 changes artifact: 0a23a72d user: dgp
16:17 Ticket [8bee4b20]: 3 changes artifact: af16d17b user: bll
14:55 Ticket [8bee4b20]: 3 changes artifact: 31b4d282 user: jan.nijtmans
14:48 Ticket [8bee4b20]: 3 changes artifact: cbe31271 user: bll
14:47 Add attachment progressbar-scaleddemo-87.png to ticket [8bee4b20] artifact: e1510dd6 user: bll
14:44 Ticket [8bee4b20] 8.7 : progress bar no longer displays properly with certain styles. status still Open with 3 other changes artifact: 14bbca55 user: bll
02:06 Ticket [8bee4b20]: 3 changes artifact: e6612a8f user: dgp
21:20 Ticket [8bee4b20]: 3 changes artifact: 7cb2742f user: bll
09:21 Ticket [8bee4b20]: 3 changes artifact: 09f7e226 user: bll
09:16 Add attachment ttkProgress.diff to ticket [8bee4b20] artifact: 84bee749 user: bll
08:59 Ticket [8bee4b20] 8.7 : progress bar no longer displays properly with certain styles. status still Open with 4 other changes artifact: 6c8690ae user: bll
08:58 Ticket [8bee4b20]: 3 changes artifact: c8fa8177 user: bll
08:55 Ticket [8bee4b20]: 3 changes artifact: c4ebff64 user: bll
15:31 Ticket [8bee4b20]: 3 changes artifact: 12ca053c user: bll
15:20 Ticket [8bee4b20]: 4 changes artifact: 509ac796 user: oehhar
20:04 Ticket [8bee4b20]: 3 changes artifact: a11190d8 user: bll
19:55 Ticket [8bee4b20]: 3 changes artifact: 2e4fc036 user: bll
19:54 Add attachment progressbar-87-awbreezedark.png to ticket [8bee4b20] artifact: 85d07118 user: bll
19:54 Add attachment progressbar-87.png to ticket [8bee4b20] artifact: 2feabd94 user: bll
19:54 Add attachment progressbar-8611.png to ticket [8bee4b20] artifact: bf707428 user: bll
19:53 New ticket [8bee4b20] 8.7 : svg change ?. artifact: 3a3fcf20 user: bll

Ticket UUID: 8bee4b2009d58a9399c91064ba981671ab38944b
Title: 8.7 : progress bar no longer displays properly with certain styles.
Type: Bug Version: 8.7
Submitter: bll Created on: 2021-06-10 19:53:50
Subsystem: (unused) Assigned To: nobody
Priority: 5 Medium Severity: Minor
Status: Open Last Modified: 2021-06-21 21:14:43
Resolution: None Closed By: nobody
    Closed on:
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.
User Comments: bll added on 2021-06-21 21:14:43:
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?

fvogel added on 2021-06-21 20:14:15:

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:

    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))

Whith these TTK_PACK_* flags, when measuring the size the progressbar should have, ttk (in Ttk_NodeListSize()) 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 -font option of the ttk::progressbar).

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 (TkDefaultFont).

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 -text option is "". 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: .pb configure -font {Arial 1} 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 -text is ""? 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:

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.

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

Any other suggestions?

oehhar added on 2021-06-21 07:45:47:

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

bll added on 2021-06-20 23:56:24:
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.

fvogel added on 2021-06-20 20:39:12:

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:
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

(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).

fvogel added on 2021-06-20 12:03:06:

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 here.

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

fvogel added on 2021-06-19 16:46:23:

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

.pb conf -font {Arial 1}

fvogel added on 2021-06-19 16:37:14:

When removing this line (i.e. don't take TIP #442 into account in the rendering), there is no problem anymore.

Now tksvg is ruled out.

fvogel added on 2021-06-19 16:36:50:

When removing [|this line (i.e. don't take TIP #442 into account in the rendering), there is no problem anymore.

Now tksvg is ruled out.

fvogel added on 2021-06-19 16:04:36:

Can be reproduced on Windows if in the test script

ttk::style theme use default

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

fvogel added on 2021-06-19 15:11:28:
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.

bll added on 2021-06-19 13:02:45:
This is with 8.6.11, and a recent download of tksvg:

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

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 

fvogel added on 2021-06-19 11:24:34:

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 -scale 0.8 option from the image create 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?

bll added on 2021-06-18 16:57:49:
Sheesh.  I just now figured out what was happening.

dgp added on 2021-06-18 16:39:56:
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.

bll added on 2021-06-18 16:17:07:
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.

jan.nijtmans added on 2021-06-18 14:55:44:

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

bll added on 2021-06-18 14:48:43:
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.

bll added on 2021-06-18 14:44:40:
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

dgp added on 2021-06-16 02:06:53:
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.

bll added on 2021-06-15 21:20:46:
Another thought to research.
Did the -sticky setting change?  Or is honored now?

bll added on 2021-06-12 09:21:18:
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.

bll added on 2021-06-12 08:59:50:
Better title.

bll added on 2021-06-12 08:58:26:
All .svg files associated with the various progressbar themes loaded fine.
Note that the same files are also used for the scrollbars, which work.

bll added on 2021-06-12 08:55:18:
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

bll added on 2021-06-11 15:31:31:
The master branch of tksvg works fine with 8.6.11.
It might not be svg.  Someone could have changed some ttk code.

oehhar added on 2021-06-11 15:20:40:

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.