3 ms·
I think there's an interesting behind-the-scenes change that is being demonstrated here: the transition from "every app handles displaying its own menu" to "app
by rcthompson 15y ago
I think there's an interesting behind-the-scenes change that is being demonstrated here: the transition from "every app handles displaying its own menu" to "apps just export their menu structure over DBus, and another program handles displaying them" is what makes it even possible to add the HUD to all applications instead of just developing a single app that uses a HUD instead of menus and leaving the rest behind. Now that all the applications are exporting their menus over DBus, if you don't like Canonical's menu interface, you can write your own and it will work with all applications. That's pretty cool.
For instance, any one of the Quicksilver-alikes available for Linux could add a plugin that turns it into a frontend for all your application menus. The KDE Alt+F2 run dialog could do likewise. Hell, you could write a menu interface in Emacs Lisp if you really wanted to, and control all your applications from the Emacs minibuffer.
- jablan 15y agoI am not sure whether this would be possible, as menus are contextual - the launcher (QS-clone, Emacs, whatever) would have to keep your current application focused, i.e. not take over its focus in order to display its menu, right?
- rcthompson 15y agoI believe that all applications that support this do so by exporting their menu structures over DBus at all times, not just when they are focused. For context, a launcher could provide access to all application menus, but prioritize results based on which applications were most recently accessed. Or just keep it simple and go with only the most recently focused one.