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.
This is something that has been in the back of my mind for a while. I was thinking about pulse audio and how it has volume sliders for each application, but the way to access this is through some other program. I was thinking that for most cases, it would be more convenient to have a volume slider attached to the actual window (obviously, this breaks if the program making the sound doesn’t have a window).
I’ve kind of left this idea in the back of my head to simmer for a while because I’m not sure exactly which programs need to change. I was imagining that the window manager could expose some sort of api to let a widget library draw stuff in the decorations (which is a bit more than just adding a menu item – but at least for this use, the best solution would be to have a volume slider, which doesn’t translate that well into a menu item). But I don’t know enough about the architecture of the big names, and whether doing this sort of thing would require one of the components to bring a new dependency (which would probably need a bit more justification than just volume sliders :))
So, if while you are thinking about it, you could be thinking about this as a possibility, then it would be cool.
I’m not sure how useful it were to the mere user to be able to suspend processes right out of metacity.
However I thought the time was right to propose the idea, since I read about the upcoming release 3.0 which would make some api changes in gtk, so anything would be messed up anyway.
You are right that additional features would enlarge the menu, but I don’t think this would be annoying. You could try metisse to see a well overloaded menu.
Andy:
That’s an interesting idea; there was someone around here wanted to embed the entire panel a few months ago. Actually, it could be done using XEmbed; it’s rather out of the scope of this particular thought-experiment, though there’s no reason it shouldn’t be one of its own.
Oooh, I’d never heard of XEmbed before. I’ll have to read a bit about it and let it sink in for a while.