Now, we can imagine that any package might want to add menu options when it was installed, and delete them when it was removed.  Let us not concern ourselves for the moment with how a menu option and its effects are represented, other than assuming that it may be represented by an ASCII string. Rather, let us consider the ways in which a newly-installed application may wish to add menu options.  We are concerned with two kinds of menu option:

• ∀: these appear on every window menu, for as long as the application is installed.  It need not be running.  For example, Take screencast should be available when Istanbul is installed and removed when Istanbul is removed.
• ∃: these appear only on the menus of windows created by the application itself.  For example, Play should appear on Rhythmbox’s window menu, but not on other applications’ menus, even if Rhythmbox is running.  (Otherwise, how would a user tell the difference between Rhythmbox’s Play and the Play of Totem?)

Users should have the option of disabling any ∀ options which are currently installed; the full set of ∀ options would be available in some kind of settings dialogue where a decision could be made about which options belonged on the list.  It should be noted that Minimize, Maximize, Close, etc., are the ∀ of the window manager itself.

So, where should these settings be stored?

• In X properties on windows: The ∀ options would be stored as properties on the root window, and the ∃ options as properties on the windows involved.  This would be the simplest to implement, but who has the responsibility to set the property on the root window, and where does the data come from?
• In GConf: This would only work for ∀ options.  It’s presumably a better plan than keeping them on the root window, though, and we could still use X properties for the ∃ options.
• In /usr/share/applications/*.desktop: This is the way which would integrate best with package management, but would cause rather a performance hit as all the .desktop files would need to be scanned when the WM started up, and then there would need to be some kind of particularly clever window matching to work out which .desktop file corresponded to which windows for ∃.

Some kind of hybrid approach may be best: we could keep the ∀ menu options in .desktop files, and have a utility program that was run when any package was added or removed, to update GConf with the values.  Or perhaps this updating could be done in the control centre, when the user chose which subset of ∀ options they wanted.  Then we could keep ∃ options as properties on the windows, and rely on the toolkits to update them (perhaps even by parsing the application’s .desktop file).

Photo © van swearingen, cc-by-nc-sa.

1. Have a set of keys which work to “bookmark” windows, and a corresponding set of keys which mean “jump to bookmark n“.
2. Have a keystroke which means “bookmark this window using the key I’m about to press”, and allow users to press bookmark keystrokes in the alt+tab window.

It is of course important that the bookmarks are associated with a given window indefinitely, otherwise they become a lot less useful.

As a step towards the second option, I’ve written a very quick and hacky script called metacity-bookmark.  The name is a little misleading, because it should work with any EWMH window manager; it uses the window matching technique described in this post.  As usual, you’ll need X11::Protocol installed from CPAN (”sudo cpan X11::Protocol“).

Bind the program to some key or other, which we’ll call Bookmark from now on, and then you can do:

• Bookmark + key — jump to the window identified by key
• Bookmark + Space + key — identify the current window by key

Feel free to play with this and let me know what you think.  I’ve made little windows pop up to tell you the program was running, inspired by the “Compose” indicator that used to appear onscreen on old DECs, if my memory serves.

One obvious limitation of the current script is that when it activates a window, it doesn’t switch to the workspace which the window’s on.  I may fix this another day when I fix all the other problems with this script, but if you fancy diving in and fixing it yourself, it shouldn’t be too hard.

As a possible extension to this, windows could also have bookmarks automatically associated with them from their creation, based on their name– for example, the first GIMP window could automatically be given “G”.  And either kind of bookmark could be displayed in the Alt+Tab switcher next to the associated window’s preview or icon.

Photo © jpre86, cc-by-nc-nd.

Update: GNOME bug 99335 is also asking for a keybinding to log out, and someone has suggested Ctrl+Alt+Delete.  Perhaps the two could be fixed at a stroke.

Update: GNOME bug 131617 is asking for a keybinding to xkill or its equivalent in the panel, which could also be fixed by having a keybinding like the one discussed above.

Photo © Gone-Walkabout, cc-by-nd.

Photo © Telstar Logistics, cc-by-nc.

Of course again we could solve this simply with an external script, and I’m wondering whether there should be a Bugzilla status for RESOLVED CANFIXWITHASCRIPT.

More seriously, perhaps there should be a collection of these scripts and a master script which listed them all in a dialogue box and modified the user’s GConf settings according to which ones were turned on.  (I wonder whether the control-center people would object to having this in an “Advanced” button somewhere, or whether that’s too bells-and-whistly.)

Update: Since the script was so simple, I spent twenty minutes writing it and closed the bug.  I think this demonstrates that we need a Perl module called X11::Protocol::Extended which knows about the EWMH, so these scripts are even easier to write.  Maybe I’ll write it.

Photo © Heated Ground Photography, cc-by-nd.

announce-wrangler.py
is the script that produces release announcements in both text form (for gnome-announce-list) and HTML (for posts like this one).  It needs some polishing.

commit-wrangler.py
puts up an editor for a ChangeLog entry, then commits current changes.  It used to be far more complicated, but now it’s merely a wrapper around a couple of calls to moap.  Stable.

patch-wrangler.py
given an attachment number on GNOME Bugzilla, checks out Metacity trunk, downloads the given patch, applies it, and compiles.  Stable, but it would be nice if it could pick up the author’s name and email address for the ChangeLog too.  That will probably have to wait for a scriptable GNOME Bugzilla.

ppa-magic.py
is supposed to build personal package archives for Launchpad with nightly builds in.  It doesn’t work at present.

release-wrangler.py
is our release script; it helps prepare the NEWS update from the ChangeLog, distchecks, builds, and uploads, but doesn’t actually run the update script on the server.  I did think of replacing this with ShipIt at some point, but their model is too different from ours.  Stable.

There’s also blog-wrangler.py which isn’t shipped, and produces the Metacity Journal, and is being gradually replaced by a more general version in Perl called ProjectJournal. Also, the Perl module Flickr::Embed grew out of the same project, though it isn’t yet in use.

Photo © Horrgakx, cc-by-nc-nd.

To play with the script:

1. Download the current version from GNOME bug 152661.
2. Put it in your path as metacity-direction.
3. Install X11::Protocol by typing:
   sudo cpan X11::Protocol
4. Open gconf-editor and set /apps/metacity/keybinding_commands/command_n, where n is any set of four unused values, to:
   metacity-direction e
   metacity-direction s
   metacity-direction w
   metacity-direction n
5. Set /apps/metacity/global_keybindings/run_command_n to an appropriate set of values, like “<Shift><Alt>Right”, etc.
6. Enjoy.

The algorithm is supposed to be the same as fvwm’s, but if you have suggestions for tweaking it, let me know.  The program should also demonstrate how to do fun EWMH things from Perl.

Photo (c) Katie Sutton, cc-by-nc-sa.

1. Veracity, a test suite.  This is about two-thirds done, but will require a bit of autotools magic to link into the main build process.  I may need some help with that.
2. Window matching: something to remember window positions across sessions.  There’s been a few requests for it recently (most recently , Launchpad bug 311615).  We’ve always said we wouldn’t do this, but maybe there’s no harm done in trying it in a branch as an experiment.
3. Opacity, a simple WYSIWYG theme editor.  About a quarter to a third of it is written.  Probably would be best to make this a separate project.
   
4. Actions.  The idea has often come up (e.g . GNOME bug 345233) that if there’s something you can bind a keystroke to, you should be able to put it into the window menu or make it a titlebar button or whatever.  This may be over-configurable, but there may be advantages of a simplified architecture in making it possible at all. There’s experimental code to do this, but it’s about half done.
5. “Cringe”: how much can we avoid keeping in memory at once?  This is an answer to what I think is our oldest current bug , GNOME bug 144242.  Saving a few bytes here and there per window can really add up.  I’ve done a small amount of playing around with this, but more is needed.  Having Veracity working will really make this easier because then we’ll just be able to run a stress test inside valgrind.

Gentle reader, which should be moved out of Metacity Labs first?

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.