Focus stealing

Focus stealing

Posted Aug 18, 2005 23:29 UTC (Thu) by zblaxell (subscriber, #26385)
In reply to: Focus stealing by newren
Parent article: GNOME and the way forward

From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)

There are one or two differences, especially in the select-no-entry case. With a grab you can have the user click on some non-menu surface, and keyboard accelerators can be used no matter where the mouse is. I'd imagine some users believe that they'd have to click off-menu to abort a menu selection (I once believed that, and it might be true for some applications with a do-it-yourself toolkit) as opposed to pressing Escape, or clicking on-menu and dragging off. Also, arrowing your way through the menu instead of using the mouse works only if the application that posted the menu already has keyboard focus for other reasons. Some menus in some toolkits will close if focus goes to another application while the menu is active. However, despite all the small changes, no menu that I've ever seen becomes unusable--all possible options, including "none of the above" can be selected with both keyboard and mouse.

I wouldn't be surprised if there weren't a lot of applications out there that are built assuming the GUI toolkit is incapable of receiving input from other widgets while a menu is active. That would probably break a few programs, but none of the ones I've tried.

---

(Log in to post comments)