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 > >> _______________________________________________ > >> Gnome-accessibility-devel mailing list > >> [email protected] > >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > >> > > > > _______________________________________________ > > Gnome-accessibility-devel mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > > > -- > Nagappan A <[EMAIL PROTECTED]> > 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
