Thoughts about a standard new feature policy

Havoc linked today in a discussion on bugzilla to a document he wrote three years ago about what features maintainers should consider adding to mature software. The central thesis is “ask ‘why’, rather than ‘why not'”. If we’re to have stability we can’t add features for the hell of it.

I wonder whether we could make a sort of checklist out of the list given there, and use it to measure rationales in feature requests (even those in patches!) as a sort of triage; if a request didn’t measure up, we could always send it back and ask them to address those points as well. I would seriously like to have a common policy across all requests so I knew my review was balanced.

2007-12-05: still not a journal

Iain’s compositor patch had some glitches and therefore didn’t make it into trunk this weekend, but I’m still hopeful it’ll be in within the week. Digg has picked up the story. And some people used Coverity’s source checking system to find some bugs, which they raised.

Also, a live point of discussion: Some people like to use alt and a mouse button for menu, resize and move. But some people only have two mouse buttons. What should we do about that?

2007-11-28: All our journal entries are busy; please hold

This still isn’t a complete roundup of yesterday, but:

GNOME bug 500279: theme inefficiency: Iain continued to rock on by finding and fixing quite a major inefficiency in the theme code: values which could have been cached weren’t. Thomas began to review the patch last night, but it was a little too much to take in in one go. It’s all rather wonderful: thanks, Iain!

Compositor rewrite: Still on the verge of being able to start making the call about putting it into trunk. If anyone wants to come around and make real life less complicated so there’s more time for patch review during the week…

GNOME bug 150897 has had some dupes recently. The Windows key or whatever you want to call it is a thornier issue than you might suppose. We generally make it a modifier key, perhaps the one which X calls Super— a hangover from the Space Cadet Keyboard— so that you can use it in combination with other keystrokes in the same way you can Ctrl and Shift and Alt. (There’s Super-R for run, and so on.) Some people think that this is a bad idea and that the Windows keys shouldn’t be modifiers (these people never want to do Super-R). Some people want to keep Windows=Super, but also have the key pressed on its own being able to cause an effect (namely to put up the main menu, as it does in Windows). But there is no current case, as far as I know, in which you can make a modifier perform an action without actually modifying something else. (I don’t think, for example, that you can configure Metacity to minimise the window when you press and release Ctrl.) Apparently IceWM does this to some people’s satisfaction, so I expect we should look at how they manage.

GNOME bug 114384 has also had a few dupes. As mentioned yesterday, we need to support startup-notification. Elijah points out that we already link to the relevant library, so this may not be very hard.

2007-11-27’s not-quite-a-journal

Life is still hectic for the maintainers this week, so this will be a short post.

On that theme, GNOME bug 468075, about a problem with vertical maximisation (which has been said to be a simple, reproducible bug, although it’s about a feature that most users don’t know exists) is not yet fixed. Someone complained that it raises the question of whether Metacity is still maintained. We are here, though; we’re just doing the best we can with the resources we have. Help is always welcome.

GNOME bug 500047 was a request to add the “busy cursor” when Metacity starts an application in response to a keystroke. This requires using startup-notification, which makes it a dupe of GNOME bug 114384 (that one’s been around a while; we should bump up the urgency).

Apparently we reached GNOME bug 500000 the other night, though it was actually a dupe of GNOME bug 500002.

Continued absence of dolphins

Sorry for the lack of daily “journal” posts over the past few days: I’ve been rather busy with real life, and it takes rather a while to gather up the crumbs to make a post. I’ve been writing a script off and on which will do the donkey work and let me or anyone else simply write the human part, but it’s not quite finished yet.

To be going on with, here’s the fascinating saga of negative numbers in theme files (well, more of a bug, really: Njáll Þorgeirsson does not have a starring role.) Someone complained that they couldn’t put negative numbers into theme files; Thomas closed the bug because the source comments (but not the documentation) say explicitly that negatives aren’t allowed. Besides, what good would they be? The reporter said that there was actually no reason to need negative literals because expressions which yield negative numbers can always be written instead. Certainly this does need documenting explicitly.

Havoc then pointed out that it makes little sense to prohibit “-1” but allow “0-1”. A long discussion of the semantics of the original comment followed. Nobody could remember ever writing it or quite what its subtleties were. Did it mean that unary negation wasn’t implemented because negatives weren’t allowed for some unstated reason, or did it mean that negative literals weren’t allowed because unary negation would over-complicate the parser? Perhaps it does make sense to prohibit “-1” if it means the code will be more maintainable? Maybe code could be shared with some existing expression parser? The issue has not been resolved.

In other news: congratulations to contributor Alex Turner (plexq on irc, aturner in svn) who got svn access yesterday after two very useful patches.

Thomas is aware that patch review is a little behind again (see above under “rather busy with real life”) and will try to get it back on track by the end of the week.

We get letters: two projects

Nigel Tao writes:

Hello. I’ve been reading http://blogs.gnome.org/metacity/ with great interest, and was wondering if you had any thoughts on my superswitcher program? People occasionally ask me if I’d push some of it upstream, which presumably means into metacity.

I asked which parts people wanted pushed upstream, and he said “the replacement of the existing alt-Tab behaviour”. I think this sort of behaviour replacement largely belongs in add-in programs like superswitcher and Devil’s Pie, for example, where they just use the EWMH to take over part of Metacity’s functionality, Metacity stays out of the way, and it makes Metacity a little bit simpler.

I think we should probably have some central place, maybe on live.gnome.org, where we list add-in programs such as these. Your thoughts, gentle readers?

(Nigel also raises the question of whether ctrl-alt-left from workspace 1 should switch to workplace n, which I think has been raised before, but I can’t find a record of. Update: GNOME bug 89315 and about a million dupes.)

Meanwhile, gandalfn writes:

Hello,

I see recently that Iain work to integrate compositing in metacity. I’ll also work on composite manager (outside metacity) which use cairo for rendering. I have implemented it outside metacity to preserve his
functionalities. My principal goal was to provide compositing in GNOME and on all platform. For that, CCM used cairo and his backends to render (Xrender/Glitz).

What about joining our efforts to provide compositing on GNOME ?

CCM is using GObject for object model design and provides a plugin system which can be used to add various effects. In the future, I’m planning to add a clutter backend, some means for other applications to interact with cairo-compmgr (especially accessibility applications), some cool plugins, etc.

Iain, and everyone else, what do you think? For myself, I think gandalfn’s compositor looks to be both more complicated (with a plugin system) and less finished than Iain’s, but as it grows we’ll see how it looks; even if/when Iain’s compositor is a standard shipping part of Metacity, it’ll be possible to turn it off and use another one, in the same way that Nigel’s been doing with superswitcher. Then if other compositors come along in the spirit of Metacity with good ideas, it’ll be possible to switch parts around and so on.

All email quoted by permission. Image: Stamp FR 387, Postverk Føroya; released to public domain.

raise_on_click: not what you think

There is a GConf key called /apps/metacity/general/raise_on_click. It does not, as is widely assumed, cause windows to be raised when they’re clicked. You should never turn it off. Doing so will make your user experience confusing in subtle ways.

The short description of the key in the current schema says that it controls whether raising should be a side-effect of other user interactions. In other words, this key would have been better named “raise on click and also on a shedload of other random things like resizing”. The longer explanation runs:

Setting this option to false can lead to buggy behavior, so users are strongly discouraged from changing it from the default of true.

Many actions (e.g. clicking in the client area, moving or resizing the window) normally raise the window as a side-effect. Set this option to false to decouple raising from other user actions. Even when this option is false, windows can still be raised by an alt-left-click anywhere on the window, a normal click on the window decorations, or by special messages from pagers, such as activation requests from tasklist applets.

This option is currently disabled in click-to-focus mode.

Note that the list of ways to raise windows when raise_on_click is false does not include programmatic requests from applications to raise windows; such requests will be ignored regardless of the reason for the request. If you are an application developer and have a user complaining that your application does not work with this setting disabled, tell them it is their fault for breaking their window manager and that they need to change this option back to true or live with the bug they requested. See also bug 445447, comment 6.

(See also GNOME bug 326156.)

We still regularly receive bugs complaining that turning off raise_on_click breaks things. This is expected behaviour:

  1. We told you not to turn it off.
  2. raise_on_click doesn’t do what the name implies anyway.

We have to keep the key for backwards compatibility, but please, everyone, just leave this key the heck alone and turned on. Thanks. :)

2007-11-17: some releases and some discussions

Two point releases out: development 2.21.2 and stable 2.20.1. Federico’s patch went into both, since it fixed a regression; Benjamin’s patch went into the development release.

It is hard to think of a shorter way to say “Make this window follow me when I change workspaces”.

Alex Turner provided a patch to make urgent windows on other workspaces appear in the alt-Tab popup, since they already appear in the pager. The patch wasn’t quite in time for 2.21.2, but should be in 2.21.3 if all goes well. So should a first attempt at merging Iain’s compositor branch, if everyone is happy about it.

Marcus Lundblad points out that the double-click to close patch doesn’t apply to trunk any more; Thomas promised to fix it and therefore will, but perhaps not until things calm down a little. Maybe when we get into freeze.

Iain’s compositing post continued to be the scene of much discussion.

Photo: The King Harry, St Albans. Photo by Gary Houston, public domain.

2.21.2 is out

Thanks to Benjamin Gramlich, Thomas Thurman, and Peter Bloomfield for improvements in this release.

  • Theme parser is compliant to XDG Base Directory Specification in searching for theme files. (Benjamin)
    (GNOME bug #480026)
  • Some source files which didn’t get used were removed (Thomas)
    (GNOME bug #496947)
  • Fullscreen and maximise windows don’t try to save their position (Peter)
    (GNOME bug #461927)

Translations: Matej Urbančič (sl).

Source downloads from the usual place; md5sums are:
0579a8b5df6faeb647607086d0d8dc09 metacity-2.21.2.tar.bz2
591225ba7b04d85176385ff50f940653 metacity-2.21.2.tar.gz

Photo: Ver valley. Photo by Gary Houston; public domain.

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