Re: GtkWidget::visible

[Tristan Van Berkom <tvb gnome org>]

On Thu, Jan 17, 2013 at 11:59 AM, Tristan Van Berkom <tvb gnome org> wrote:
> 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).

I realize this wasn't the most constructive reply, I've been busy
and planned to reply to this when I initially received it, so wrote
a reply in a hurry.

What I think we're looking for here, is just an alternative way to iterate
over container children, i.e. a convenience API that would iterate
over only visible children.

I'm only a bit wary of removing the capacity to request the size of
an invisible widget, since that can also have it's uses.

With an alternative API, like gtk_container_foreach_visible(), or
gtk_container_list_visible_children(), we could eliminate all of those
statements which exist in GtkContainer size request/allocate
implementations which basically all already do:

if (!gtk_widget_get_visible (child))
   continue;

It might not be too much code reduction, but would probably make
things more readable (and easier to implement, it can be easy to
forget to skip the invisible widgets when implementing containers).

Cheers,
          -Tristan

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