Re: [g-a-devel] Focus - AT vs. mouse/keyboard manipulation

["Elijah Newren" <newren gmail com>]

On 8/14/06, Bill Haneman <Bill Haneman sun com> wrote:
> (cross-posting to metacity-devel, because I don't know how to fix this
> and I suspect the metacity hackers will)
>
> Hi Zack;
>
> I think you're encountering several issues here.  With regard to the
> Action interface, items which aren't posted to the screen may still be
> activated.  For menu items this probably isn't really a problem, with
> respect to the desired effect for end users.
>
> For dialogs, I agree that there's a problem.  The difficulty you are
> seeing is probably a result of "focus stealing prevention" which was
> added to the metacity window manager (in the gnome-2.14 timeframe I
> think).  This behavioral change was intended to prevent applications
> from "stealing" focus except in response to a direct user action.

This is a pretty good description of the behavior, but there are some
pedantic clarifications I'd like to make (feel free to skip this
paragraph if you just want to solve your problem ASAP instead of
getting the verbose lecture):  The behavioral change was also intended
to answer the question "how do we handle the fact that user actions
are often far from instantaneous, and that users will continue issuing
more actions instead of waiting for the first to be processed?"
Indirect or non-user actions (e.g. Telsa sending an IM to Alan just as
he's about to type his root password into some window, resulting in
Alan accidentally IM'ing his root password back) was definitely a big
part of the consideration, but that was actually considered a special
case with a separate hint and handling for it.  It's just that, as a
side-effect of the particular implementation we chose, a broad range
of indirect interactions (e.g. the IM case) automatically worked
without the additional hints.  But you are right that the AT-SPI
actions are being lumped into the latter case because you haven't
provided the WM sufficient hints to do otherwise.  This is actually
very similar to another case:  single-instance application launches
(where the second instance would request the first to open a window
for it, and then the second instance would shut itself down) suffered
from the same problem until they fixed the hints provided to the WM.
Oh, and the other pedantic clarification -- this was introduced in the
gnome-2.10 timeframe (well, developed during the gnome-2.6 timeframe,
added in gnome-2.8, removed at the last minute because of insufficient
support for the new spec, and then finally landed in gnome-2.10).

> However, I believe that the AT-SPI Actions should probably be treated as
> "user" actions even though they are technically 'programmatic' ones.  I
> don't know whether new metacity or window-manager API would be required
> to make this work, or not.  For this reason I am cross-posting your
> message.

No additional window manager API is required; it long since added all
API you need -- you just need to use it (see below).  You may
need/want new AT-SPI API, though.

> Metacity folks: if an end-user of an assistive technology such as a
> screen reader or onscreen keyboard invokes the "activate" action on a
> button which opens a dialog, the desired behavior is for that dialog to
> take focus, since it is being posted in response to an end-user action
> (albeit indirectly).

If it's a response to a direct user action (e.g. mouse button press on
a button of the onscreen keyboard or such), then you have the
timestamp of that user interaction.  If you just forward it to the
other process, and have the other process call
gdk_x11_window_set_user_time(gdk_window, timestamp) on the relevant
window, then you're good to go.  (If you want to do this on a widget
that hasn't been shown yet, you may be unable to obtain a gdk_window
unless you first call gtk_widget_realize())

> I am happy to annotate the AT-SPI docs to warn clients of the API that they
> should not use the Action:doAction API except in response to direct end-user
> requests.

If it's not in response to a direct end-user request, just don't send
a timestamp and do no updating of timestamps on the other end.  Then
metacity will automatically treat it correctly.

Hope that helps,
Elijah