Today, in my quest to make things clearer in the GTK core, I'm
tackling GtkWidget::visible.
The flag is documented as "Whether the widget is visible."[1] or a bit
better in the documentation for gtk_widget_show() as "Any widget that
isn't shown will not appear on the screen."[2]
However, this doesn't say anything about sizes, in particular sizes
requested from a widget. So far, GTK would not check the visibility
flag when calling size request functions ad would happily allocate a
size to a hidden widget. It also would happily expose the widgets to
the accessibility APIs. This has a bunch of problems:
- performance suffers
If we need to compute all these things for widgets we're not going to
use anyway doesn't make Stuff Go Faster.
- containers don't know what to do
Should they skip invisible widgets when allocating? Or still reserve
space for them?
- developers implementing widgets get confused
Can they optimize things away when their child is not visible? Like
can I skip the whole CSS machinery for hidden widgets in GTK?
- developer expect those widgets to not do anything
A11y people have lots of "fun" fixing bugs when Orca pokes into
widgets nobody expects to be pokable. Usually developers just hide()
widgets when they are supposed to be unresponsive and invisible and
then they don't update them anymore and expect no callbacks to happen
from them.

So as a result, 2 things are going to be changed:
(1) gtk_widget_get_preferred_width/height() will return 0
With a recent commit[3], GTK will shortcut all
get_preferred_width/height() to return 0 for minimum and natural sizes
for all invisible widgets. Also, the allocation of the widget will be
immediately recent to an invalid state, so gtk_widget_get_allocation()
will return the initial { -1, -1, 1, 1 }.
(2) A11y code will ignore invisible widgets
We're working on a patch that will make sure no accessibles show up
for invisible widgets.[4]

Why am I writing this? Because if you happen to run code that breaks
due to these commits or think this is a bad idea in general, you now
know that it's happening and still have a chance to stop us before we
release this as GTK 3.8.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]