January 2009 – Page 2 – …for the adult in you

Inbox zero

It’s been a few weeks since the Western new year (though the Chinese new year is coming up), so it’s a bit late for resolutions, but let’s pretend. There are currently 447 open bugs on the Metacity bug tracker, which I think is an unsupportable situation. So let’s say that by 25 January 2010 all the bugs will have been dealt with.

That’s a bit more than one a day. I’m going to need help. Will you help me?

Out of these, 19 are tracker bugs and so don’t count towards the total. These would be better done with keywords, anyway.

There are a few crashers which are either reproducible or they aren’t.

Most of the bugs are squibs, ideas that someone raised for us to consider. Some of them have patches. We need to decide one way or the other whether these are going in. For the ones which aren’t, we need to decide a place to keep all the patches which didn’t make it in. This can be done with a wiki page linking to all of them; when we have a DVCS, we could also have a branch for each.

I think I’m going to introduce a Bug of the Day feature here where we discuss the possible impact of each such bug.

Thoughts?

Metacity and D-Bus

GNOME bug 531512 suggests that Metacity should have a D-Bus interface. On the face of it, this is a good idea. However, the problem lies in the existing EWMH specification, which allows a program to request operations from a window manager– simply put, it’s pretty much exactly what a D-Bus interface would be, but it already exists. If we also exposed a D-Bus interface, even one called “org.freedesktop.WM” instead of “org.gnome.Metacity”, we wouldn’t be gaining anything we don’t already have, and then people would begin using it and their programs wouldn’t be compatible with other EWMH window managers. So every WM that implements the EWMH would have to expose the same D-Bus interface, which sounds like a lot of work for not much return. On the other hand, we could have a separate program which exposed a D-Bus interface which translated the methods into EWMH messages, and which could be used with any EWMH window manager. Would that do as well? What do you think, gentle reader?

Photo copyright Zarko Drincic, cc-by-nd.

Any autotools geniuses out there?

I can’t tell why this setup doesn’t compile test/veracity/veracity.c. What am I missing? I freely admit I suck at autotools.

(veracity there is not much like the version which will end up being merged at all– it’s just the bones.)

Themers

I think most people who design Metacity themes don’t read this blog, which is a shame because they’re a particularly specialist bunch of users and I’d like their opinions on things. Does anyone know where enough of them hang out that I could contact them? Or should I just bcc contact addresses in a bunch of theme files and suggest they come over?

The answers page

Feel free to ask more questions, but here are answers to the ones you asked already:

How would you make a Prelude theme? Answered here and now floating around the net.
Will the compositor ever be enabled by default? I’d like it to be. There are apparently people it still doesn’t work for well, though. Perhaps as newer hardware becomes more common this will become less likely.
Will there be new features in the compositor? Possibly. It seems to be working fine now, and I don’t want Metacity turning into a knock-off of Compiz. But I can imagine some kind of plugin-based thing happening in a wild handwavy future, and in the meantime plenty of people are asking whether the shadows can become adjustable.
What is Metacity’s role in GNOME Shell? GNOME Shell uses a fork of Metacity called Mutter (i.e. Metacity with Clutter). Whether this will become the main Metacity in future, or whether the two will be developed in parallel, or whether it’ll be merged back upstream and have some way of controlling which control path is taken, is not yet decided. I need to talk to the Mutter people more, anyway.
How about window matching? Raise your voice about option 2 of this list.
Can Metacity move the title bar from the tops of windows to the sides? Not in versions 1 or 2 of the theme format. Maybe in version 3 this will be possible, if there was any use for it: it’d be a fairly simple change to the existing system.
Why not merge Metacity and KWin and have one über-window-manager? Because choice is good. That’s why we have EWMH, so you can run KWin with GNOME or Metacity with KDE if you really want. Trying to reduce choice in window managers, or desktop environments, or whatever, really ends up with the choice of The Non-Free Market Leaders versus Everyone Else, which really isn’t much of a choice. (But we do talk to Luboš and the other WM maintainers, and they’re all fine people, and we’re not attempting to sabotage one another’s work. We’re even holding the conferences in the same place this year, you know…)

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.)

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.
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.
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.
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.
“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?