Re: GtkWidget::visible

[Tristan Van Berkom <tvb gnome org>]

On Wed, Jan 9, 2013 at 12:04 AM, Benjamin Otte <otte gnome org> wrote:
> Hey,
>
> 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?

That's not exactly true. All containers know what to do with invisible
children, all containers skip invisible children when requesting and
allocating sizes. They even have the option of doing different things
depending on the container type or the child properties of the given
invisible widget.

For instance, it can be useful in notebooks if the notebook reserves
space for invisible children, this way the notebook size does not
jump/change whenever one of the optional pages is shown/hidden
(I can't seem to find it, but was sure there was a
"request-space-even-if-invisible"
child property in one of our containers).

In any case, if we really want to do something drastic like this,
we should modify all the containers at the same time so that
they actually dont know what to do with invisible children anymore...

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

I don't think this is exactly right.

There can be reasons to calculate the size of a widget regardless if it is
mapped or visible.

One example could be when creating a target surface for gtk_widget_draw().

Cheers,
           -Tristan


> (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.
>
> Benjamin
>
>
> 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible
> 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show
> 3: http://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515
> 4: https://bugzilla.gnome.org/show_bug.cgi?id=577392
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list