Rodney Dawes wrote: > I don't think there's any reason to try and avoid doing so. During > automated testing, of this sort, you need to avoid using the keyboard > and mouse, as the tests will be entering data into fields in the UI, > and moving the mouse and typing on the keyboard, can interfere with > that and cause problems in the testing. Having grabfocus bring the > window to the front is the proper thing to do, IMO. > For automated testing, you could call grabFocus on the toplevel window first, so either answer to the question below (do/don't pop toplevel to top when calling grabFocus on an internal widget) would work.
Bill > -- dobey > > > On Mon, 2007-02-12 at 23:03 -0700, A Nagappan wrote: > >> Hi, >> >> Attached a patch to grabFocus on any accessibility component in >> http://bugzilla.gnome.org/show_bug.cgi?id=347481 >> >> ---------snip starts------------ >> Bill's comment on the bug: >> >> We should ask the list (g-a-d) whether clients think grabFocus should >> pop the >> window to the top, even when called on a subcomponent (as opposed to >> just a >> toplevel window). >> ---------snip ends------------ >> >> Any comments / objections ? >> > > > _______________________________________________ > 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
