Divider widget not showing unless the box that contains it has flex=1

[bruno-rino]

A picture is worth a thousand words, so...

This is what the Divider example looks like:

If you resize the window, the vertical divider extends:

That's because the box that contains it has flex=1

toga/examples/divider/divider/app.py

Line 30 in b5d3802

style=Pack(direction=ROW, padding=24, flex=1),

I thought, this flex=1 doesn't make sense, let's remove it. But then the Divider doesn't show:

[freakboy3742]

Good catch. Agreed that the divider should be expanding into as much space is available by default, without the need for a flex (although adding flex=1 is a painless .

Interestingly, the same problem doesn't appear to exist on the horizontal widget.

Another interesting data point - GTK has the same problem, but winforms doesn't - despite an substantially similar implementation. There's probably some underlying difference in how the intrinsic widget size has been calculated.

[bruno-rino]

Adding flex=1 is not really painless fix. It needs to be set on the Box that contains the Divider, and that has side effects like the second screenshot shows.

The problem does appear on the horizontal widget. Where is does not appear: if the divider is a direct child of a Box with predefined size, like the top-level Box of the window. This code highlights the issue: https://gist.github.com/bruno-rino/b5902f8e65839813fbf154572da7c2dc

I'm preparing a PR to fix the issue. Only tested on macOS.

[ikus060]

Hello, seeing this bug open since 2022 and now we are 2024 get me a bit worried.

Is any body working on this kind of bug fix ? I got the impression the project was in active development.

[ikus060]

I had a look into the Pack style and it seams to be missing a feature to properly support this.

It seams flex is used to define the weight of the widget, but regardless of it's direction. The direction seams to be inherit from the parent direction. I think it's a wrong assumption. Similar to the Pack geometry manager provided by Tkinter, we need to distinguish between the weight of the widget and the direction to expand too.

To take the same example, we may want both labels to expend horizontally and our divider to expend vertically. Using only flex to parameter this is insufficient. What I'm proposing it adding another parameter to Pack in order to control in which direction the widget should take all spaces either vertically, horizontally or both.

https://www.pythontutorial.net/tkinter/tkinter-pack/
See Expand (identical to flex) and fill

Am I correct and may I proceed with a fix ?

[freakboy3742]

I'm not convinced you've correctly identified the problem.

We can't arbitrarily add features to Pack, as whatever we add to Pack needs to have a mapping to pure CSS. Flex has a very specific interpretation, directly taken from the Flexbox design in CSS.

I don't think this is a lack of features in Pack as a language; it's an issue of the implementation of the Divider widget itself - or, at the very least, the interaction of Divider with pack. The correct amount of space is being allocated for the parent box; the issue is that the intrinsic size of the Divider isn't causing the widget to fill that available space provided by the parent. Once space has been allocated, the widget should be drawn to fill that space. On macOS and GTK, this isn't happening for some reason. On Winforms, however, it does. I don't think this requires an additional feature in the external API of Pack - it requires an internal API and implementation change.

As for questions about whether the project under active development - inspecting the commit log (or the monthly status reports on the BeeWare website should address that. Just because there's a known bug that has been open for a while doesn't mean the project isn't being actively developed. It means that the people doing the development have made the diagnosis that the problem that has been reported isn't as critical as other problems that currently exist. In this case, it's a niche problem with one widget with a workaround that, while not ideal, exists.

[jepler]

I looked at this at PyCon and didn't figure out a solution. It looks like the layout engine (core/src/toga/style/pack.py) is determining the height as 0 pixels, but then I don't know why Windows wouldn't have the same problem since it's common code...