Tk Source Code

Thank you for your feedback!

I have now merged branch bug-bc602049ab containing a new test treeview-bc602049ab exercising the original testcase with added -width 0 -height 0, and a documentation complement in ttk_image.n about this case. The other changes merged from that branch are cosmetic.

Many thanks to Peter Spjuth again.

Huge thanks to everyone for helping to fix this issue! After all, using "-width 0 -height 0" to fix this unwanted behavior is kind of logical.

Thank you all,
rdbende

Peter, this is simply brilliant, many thanks for your feedback!

After digging into this more and more I came to the same conclusion: my "fix" [d507fe93] is plain wrong, for the exact reason you give.

What I didn't have is the idea to specify "-width 0 -height 0", which solves the problem indeed. How logical and brilliant! The ttk code correctly constructs the size of the treeview from the elements used in its layout. But TreeviewSize() thinks that this size is the size of the padding only. But this is only true until the field element gets reengineered to become an image, like in the original testcase. With such an image field element specified with "-width 0 -height 0" it is still displayed without taking any size in the treeview layout. Brilliant!

Note that in the original script, even just after packing the widget, the height of the widget is wrong (20 pixels too large) too, due to the same cause: the background image has 20x20 pixels size. On 'ttk::style theme use ...', the widget resizes because after its size is computed the calculated width gets entirely redistributed among the (displayed) columns. Then upon next 'ttk::style theme use ...' the width is added once more to the sum of the (displayed) columns widths. And so on. This does not happen for the height because the widget height does not get redistributed among the rows of the widget, but the widget height is nevertheless wrong.

The only workaround I can find is to do this:

```
ttk::style element create Treeview.field image tvbg -width 0 -height 0
```

thus creating an element that do not request any size.

The proposed change in bug-bc602049ab I do not think can work since it no longer adds the padding and any -padding setting will fail.

I think I have found an error in the code, which was producing this problem.

See commit [d507fe933c]. This fixes the wrong behavior exercised by the original test script.

However this change triggers two failures in the test suite, that I have yet to understand:

==== treeview-9.2 scrolling on see command - bug [14188104c3] FAILED
---- Result was:
0.0 0.9 1
---- Result should have been (exact matching):
0.0 1.0 1
==== treeview-9.2 FAILED

==== treeview-ce470f20fd-4 changing -stretch resizes columns FAILED
---- Result was:
60 50 60 50 58 50 1
---- Result should have been (exact matching):
60 50 60 50 60 50 1
==== treeview-ce470f20fd-4 FAILED

Please test branch bug-bc602049ab and report any weird behavior or regression with the ttk::treeview widget.

After digging a bit into this, I believe this is a conceptual bug. When running "ttk::style theme use ..." a virtual event <<ThemeChanged>> is generated for all ttk widgets.

This event is handled in CoreEventProc (ttkWidget.c lines 308+). This code calls UpdateLayout(), which recomputes the size of the treeview layout using TreeviewSize(). TreeviewSize() calls Ttk_LayoutSize(), which calls Ttk_NodeListSize(), which calls Ttk_NodeSize() as needed for all nodes.

When the treeview widget has no background image, this goes well because the resulting size is zero (or just the padding), leading to a treeview size of the width of the columns: *widthPtr = padWidth + TreeWidth(tv) is simply TreeWidth(tv) in TreeviewSize() since padWidth returned by Ttk_LayoutSize() is zero.

But when the treeview has a background image element added as in the demo script, then the call to Ttk_LayoutSize() (ttkTreeview.c:1650) returns 20 (instead of zero) for both padWidth and padHeight, i.e. it states that the treeview field element has size 20x20, which is the size of the elementary image that gets replicated to fill the treeview background (see "Image stretching" in the ttk_image man page).

Basically, with a background image element the treeview layout size depends on the size of the image displayed in that background. This just sounds like it makes sense, except there is this undesirable effect that the present ticket is reporting.

I'm unsure about what should be done in this situation. Ideas...?

Thanks for reporting.

I can reproduce with Tk 8.6.12

Here is the original github ticket for reference: https://github.com/rdbende/Azure-ttk-theme/issues/40#issuecomment-1215618136