Re: GtkWidget::visible

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).
> 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().

Another example is when using GtkSizeGroup, you dont want all your widgets
in the group to suddenly become bigger because you just called gtk_widget_show()
on one of the optionally visible members of the group (hence the "ignore-hidden"
property on GtkSizeGroup to override this default behaviour).

> 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:
>> 2:
>> 3:
>> 4:
>> _______________________________________________
>> gtk-devel-list mailing list
>> gtk-devel-list gnome org

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