Recently, Markus Weißbacher raised GNOME bug 545627 to ask for a new menu option which suspended a window’s owning process. Now, it’s not particularly difficult to do this, and to some people (presumably Markus, at least) it’s useful, but there are hundreds of things we could put on the window menu, and if we put them all on, it would end up looking like a restaurant menu with hundreds of choices (especially with sub-menus– you know, biryani linking to chicken biryani, prawn biryani, and so on, vindaloo to lamb vindaloo, and… sorry, I got kind of distracted there). This is nice if you know what you’re doing, but it does rather terrify the users, and if you know you want one out of a small number of things every day it might be faster for you to pick from a cut-down lunch menu. Do excuse me; I like this analogy, and there might be barfi at the end of it.
We could provide code for all the hundred-odd options, and then let the user choose between them in a vast gconf directory of doom, and that would solve the problem of having to show them all for everyone. But Metacity is supposed to be a lightweight window manager, and including all that extra code will make us even less lightweight than we are. For the same reason, the solution is not to embed a Scheme interpreter so people can write plugins for all the menu options they want. Nor are we going to have something like Firefox’s plugin system where the extensions handling each menu option would run in-process, rendering a previously stable window manager more brittle than a poppadom… sorry, distracted again.
So suppose we wanted to let users add options to the Metacity window menu in some kind of configuration file (ah! then we could let libwnck read the same file!), or a place in gconf, and to invoke something out of process when the user chose one of them. I see three ways to proceed:
- Fork and exec something. This is an extremely simple and nicely general solution, though the mechanics of figuring out what information is passed to the exec’d process needs some thought. We already do something like this for certain keybindings, so perhaps we can just generalise that.
- X messages to the root window which are then picked up by a daemon. Not a bad idea, and in fact we do a lot of things this way already (many of them undocumented– ooh, an idea for a forthcoming post). This does require either one daemon to be running all the time, which means if it crashes nothing will respond, or a bunch of them, which is a bit of a resource hog.
- D-Bus. This has the great advantage over X messages that if the handler isn’t running the bus will start it, and the handler can do its work and then softly and silently vanish away without ever hanging around as a daemon.
As well as adding new menu operations, this could be used to add new operations on that annual blister, middle-click and double-click on the titlebar. Perhaps the idea could even be used to add new button actions, although adding new types of buttons with the current theme version is generally impossible, because all themes must describe all types of buttons and all types of buttons must be described by all themes.
Translation work would need to be carefully coordinated with such a system, too, especially if we started moving existing actions (which are all already translated) out of the code and into the list.
So, anyway, this was my thought experiment for the day. I’m not necessarily going to do anything about it, or at least not now, but I thought it might be a simple way for people to get what they wanted without the risk of messing up the world for everyone else.
Photo by Lakesidey. cc-by-nc-sa.