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

["A Nagappan" <anagappan novell com>]

Hi Bill,

  Just fixed in CVS, you can test it with the following code:

from ldtputils import *
from ldtp import *

launchapp ('gedit')
grabfocus ('*-gedit')

Thanks
Nagappan

Nagappan A <anagappan novell com>
Linux Desktop Testing Project - http://ldtp.freedesktop.org
http://nagappanal.blogspot.com

Novell, Inc.
SUSE® Linux Enterprise 10
Your Linux is ready™
http://www.novell.com/linux


>>> Bill Haneman <Bill Haneman Sun COM> 08/14/06 8:05 PM >>>
On Mon, 2006-08-14 at 15:03, Nagappan wrote:
> Hi Bill,
> 
> Test case is available here -
> http://bugzilla.gnome.org/show_bug.cgi?id=347481

I don't think that's really a valid test case for the problem I was
describing.

It's not clear to me that grabFocus() should work on a component in a
window that isn't active.

regards

Bill

> 
> Thanks
> Nagappan
> 
> Bill Haneman 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. 
> > 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.
> >
> > 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).  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.
> >
> > Zack, a specific test case that we can use for diagnosis and discussion
> > would help.  Do you have one in mind?
> >
> > Best regards,
> >
> > Bill
> >
> > On Wed, 2006-08-09 at 21:57, Zack Cerza wrote:
> >   
> >> Hi,
> >>
> >> If I do something that results in a dialog popping up via either the 
> >> mouse or the keyboard, that dialog has focus. If I open the dialog via 
> >> AT-SPI's AccessibleAction interfaces (e.g. 'click' and/or 'activate'), 
> >> the dialog does not have focus. Now, it seems that this would be 
> >> considered a bug, but even if it isn't, I can't seem to find an 
> >> alternative way to ensure that the dialog is given focus.
> >>
> >> I did try using AccessibleComponent_grabFocus() on Accessibles which 
> >> implement that interface, but ran into problems; for the vast majority 
> >> of AccessibleComponents, the function returns FALSE, indicating that it 
> >> was unsuccessful (which it was). Why would that function always fail?
> >>
> >> I did find that most (if not all) Accessibles with an 
> >> AccessibleEditableText interface can successfully grabFocus, but even 
> >> then, the window or dialog they're in must be focused; they will not 
> >> grab focus from another window.
> >>
> >> So, my question is: How can an AT ensure that the same windows and UI 
> >> controls that have focus after a given user action (i.e. with just the 
> >> keyboard and/or mouse) is performed have focus when the same workflow is 
> >> performed by the AT?
> >>
> >> Thanks,
> >> Zack
> >> _____________________________ http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >>     
> >
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >   
> 
> -- 
> Nagappan A <anagappan novell com>
> Novell Software Development (I) Pvt. Ltd.
> Linux Desktop Testing Project - http://ldtp.freedesktop.org
> http://nagappanal.blogspot.com/
> 
> Novell, Inc.
> SUSE® Linux Enterprise 10
> Your Linux is ready™
> http://www.novell.com/linux
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel