Re: GtkWidget::visible

[Piñeiro <apinheiro igalia com>]

On 01/08/2013 04:04 PM, Benjamin Otte wrote:
> Hey,
>
> Today, in my quest to make things clearer in the GTK core, I'm
> tackling GtkWidget::visible

Some comments/questions (mostly related to the a11y stuff) below.

> - 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.
Yes, some time ago [5] Orca developers suggested that if the widget is
not "marked as visible by the toolkit" it shouldn't be exposed, as a
user can't interact with it. In the same way the current VISIBLE/SHOWING
states should be merged, and just maintain one state of VISIBLE==widget
is visible to the user. After some discussion, thats was the final
conclusion [6].

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

Makes sense.

Having said so ... as I said, the consensus was maintain the state
VISIBLE as a way to expose if the widget is visible from the pov of a
user. For example, to know if an object is exposed to the user (as the
user can interact with it), but scrolled off screen (so not visible).
But during the discussion of that bug, we also agreed that in general,
knowing if a widget is really on screen can be really costly [7]. So in
a ideal situation we have this:
  * Precondition: compute if a widget is visible on screen is feasible
  * Target: accessibility implementation only expose objects relevant to
the user.
  * gtk doesn't expose widgets with GtkWidget:visible=false, as they are
irrelevant to the accessibility framewok
  * Under previous precondition, an accessibility state VISIBLE is still
relevant, because as a user could try to interact with a widget scrolled
off the screen, it is exposed, and in the same way it is not visible, so
it would be good to differentiate one from the other.

But as I said in general that precondition is not feasible. So that
would lead that all the objects exposed will have the accessibility
state VISIBLE, because there is no practical way to decide if it is in
fact visible or not. Under that scenario, one could wonder if any
accessibility VISIBLE state is relevant at all. My opinion is that it
would be better to maintain it, hoping to find situations were the
visibility status can be computed. Anyway, any feedback about this
accessibility state is welcome, and I also hope to be wrong about not
having any situation at all were the real visibility could be refined.

BR

PS(offtopic): someday I would need to a) deprecate that SHOWING state on
atk, and b) do the same filtering on clutter. This filtering is part of
a more global filtering of objects exposed by clutter that I had in mind
since a long time ago. Right now clutter accessibility implementation
tends to expose *everything* something that is a bad idea. Anyway, this
situation became less critical thanks to the deprecation of classes like
ClutterBehaviour etc, that were exposed in the past.

> 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
[5] https://bugzilla.gnome.org/show_bug.cgi?id=648260#c0
[6] https://bugzilla.gnome.org/show_bug.cgi?id=648260#c7
[7] https://bugzilla.gnome.org/show_bug.cgi?id=648260#c6

-- 
Alejandro Piñeiro Iglesias