You can switch in a direction!

BridgeWhen I posted yesterday’s squib, I really didn’t expect six people to say they’d use it. Someone plaintively left a message on the bug saying “Please make it possible for devilspie to add this feature!” Well, it is possible for devilspie or any other addon to add this feature, and for that reason it’s not a big difficulty to write it as an external script.  As an added bonus, it should work with Compiz or KWin or any other EWMH-aware window manager.

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.

Half-finished code finishing marathon time

I have several half-finished bits of code lying around.  I think I’ll make an effort to merge them in, at least in test branches, to see what people think.  (When we get a DVCS, this will be easier.)

  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?

Thought experiments: plugins

Train'n'tunnelRecently, 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.

Build systems and version control

In GNOME bug 532353, Elijah suggests switching Metacity to waf. Your thoughts on this are requested. I will build this into the test scripts whether or not we go with it in the long term.

Also, no work is getting done (or at least checked in) until the openssh débâcle is over and gone. Would this be a good excuse to move to bzr or git? Advocate please! I like bzr, but mainly because I already use it a lot and I love Python.

Patch wrangler

While I was committing release-wrangler.py, I thought I’d also include patch-wrangler.py, which (once given a patch number) downloads Metacity trunk, applies the patch, configures, and makes. It would be better if it could figure out the project name given the patch so that it was usable on other projects, which is possible through scraping bugzilla, but that might make the bugzilla admins unhappy.

Release wrangler

Henry the WranglerI’ve written a basic release script for Metacity following the standard release instructions, since I have to go through them every week or so anyway and I thought it would be better to automate them. Of course, it took about five times longer to write the script than to do a release, but I look on it as an investment.

If you want to use it yourself, it will probably not work for you straight away; I’d appreciate help generalising it if you’re interested, though. There is an lgo page about it.

(Later, Josh suggested that it might be similar or mergeable with ShipIt, which I haven’t looked at yet.)

One question I’m wondering about: a “point release” is when you go from, say, 3.1.x to 3.2.0, right? So what do you call it when you increment the micro version number, say from 3.1.4 to 3.1.5? Is there a special name for that?

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.