I was asked on IRC to explain why it is that programs mostly cannot raise their own windows.
gtk_window_show() indirectly calls XRaiseWindow. This causes a ConfigureRequest X event. Metacity will only honour this if:
- the window belongs to the active application (but if there is no active application, any application can raise its windows), or
- there has been user activity in the new window more recently than in the active window
In all other cases it will ignore the request. If the request is to raise a window (rather than to lower it), it will set the attention hint on the window which was trying to raise itself.
This is not just GNOME being weird: here’s Lubos Lunak (the kwin maintainer) saying the same thing last year.
If you think this is a bad idea, figure out which part of it you think is a bad idea and then complain on that bug, or on wm-spec-list.
This is not the Metacity home page. There is no Metacity home page. This is for the same reason there is no flashy logo: Metacity strives to be quiet, small, stable, get on with its job, and stay out of your attention.
But this is a place where you can find out about Metacity. The maintainers and contributors post here, and we invite and provide feedback. So, what sorts of things can you expect to see here?
- Announcements of releases.
- The Metacity Journal appears semi-regularly, when things have been busy in the Metacity world. It discusses:
- notable changes to the code in the last day or so
- links back to people who have written about Metacity in their own blogs and discussion of what they say
- news articles mentioning Metacity
- activity on bugs (either on GNOME’s own bug tracker or downstream). These are often about issues which concern users, and you should always feel free to leave a comment giving your own opinion. We thrive on it.
- When there’s a lot of work being done on a particular sub-project, there will probably be regular posts on that project here. An obvious example was Iain’s compositor.
- anything else we think of.
- anything else you think of, possibly.
Comments on posts are open for the first few weeks, but are always moderated to keep the spammers away.
Photo credit: Li’l Bear. cc-by.
Someone asked on IRC whether there had been a Metacity blog post about a certain thing they were interested in. There hadn’t been, but they were interested in seeing one, and I wondered what else people would like to see. So, ask us some questions (presumably questions about Metacity; if you want to know the date of the original constitution of Colorado there’s always Wikipedia :) ). People might answer them in the comments, and some of them might grow up to be fully-fledged posts. Of course you can always email us, too.
So, now that the compositor is in trunk and everyone is excited, this might be a good time to mention some “issues”.
Firstly, it seems that there are some weird shadow redrawing problems…these just appeared recently, so it shouldn’t be hard to find the offending commit. I think I know what it is, I just need to work out why its not working.
Next: Now that some windows have argb visuals some buggy themes may have translucent parts where there weren’t translucent parts before. Gilouche was one of these themes and Jimmac fixed it up recently. So if you start seeing through the window title bars, tell your theme author.
Also, I’ve been getting reports of terrible performance and rendering issues with xgl. It seems xgl doesn’t like any of the non-GL compositors, so I don’t know what to do about that.
Finally, on a happier note – a big thank you to whoever bought me stuff from my wishlist. Its much appreciated, even if it did take me two days before I noticed my parents had piled up my mail in a weird place while I was away…
Thanks to Iain Holmes and Thomas Thurman for improvements in this version. This is the first unstable release to contain the new compositor; please try it out and let us know how it goes for you. Downstream maintainers should note that its GConf key is initially turned off in src/metacity.schemas.in and consider whether to turn it on by default in their packages.
- merge compositor branch! (Iain) (GNOME bug 499081)
- print “Subversion” and not “CVS” when building (Thomas)
Jorge González (es), Kjartan Maraas (nb), Daniel Nylander (sv)
Photo: Footbridge over the River Ver, Hertfordshire, England. Photographer: Gary Houston. Public domain.
Iain’s compositor is now on trunk since it now meets every requirement I wrote about here. It looks gorgeous. It will be in the next unstable release, which will happen before the weekend. Do not use bucket-o-bling any more; it is a dead branch. Work will continue on trunk. This closes GNOME bug 499081. All kudos goes to Iain.
Someone asked about this and I was going to tell them, but then I thought I’d say it here. I will merge Iain’s compositor branch when:
- there are no known
- large memory leaks
- security holes
- it can be turned off entirely from ./configure and GConf
- when it is turned off in GConf or ./configure, the code paths are substantially the same as before the merge
- I actually compile it myself and see it working on a computer in front of me
- there are no smaller nitpicks like coding style and so on
So far most of these have been met, but not all at once. Note that “it all works perfectly” is not a criterion: it is important that it’s easily testable in standard unstable releases. On the other hand, “Metacity is as stable as before if you turn compositing off” is a very important criterion.
A quick overview of where the action’s at in Metacity today. Not even a picture of a pub. As ever, dive in and discuss where you like, here or on bugzilla or on your own blog: we thrive on audience participation and we love to hear from you.
- GNOME bug 502644: a lot of people think the minimise/restore, and drag/resize wireframe animations are ugly, and ask to be able to turn them off in various combinations (other than the combinations you can already use).
It would be better to fix the animations, really: do any of you have any suggestions how they could look better?
Also, would anyone who doesn’t like the wireframe applications be happier once we have a working compositor anyway?
- GNOME bug 115584 (yeah, an old one): Someone wanted a way to name, and bind keystrokes to, a large number of workspaces. At the moment you can bind up to a dozen with gconf, although there’s no reason it shouldn’t be more. Thomas proposed a scheme to let users bind n instead. Havoc said it would be crazy to have 64 workspaces each with its own keybinding. Thomas conceded this point. I think this is heading towards WONTFIX territory.
- GNOME bug 436257: when you cancel a keyboard resize the arrows should be consistent whichever side you end on. We have a patch for this now.
- GNOME bug 430198: theme preview should have the theme’s name in the titlebar, shouldn’t it?
- GNOME bug 333548: Alex’s patch reviewed and is basically good; some fixups suggested
- GNOME bug 439749: someone supplies a patch to add “maximise vertically” and “maximise horizontally” to the list of things that can happen when you double-click a window; it is their first patch, and Thomas attempts to be friendly while also asking whether it’s worth adding in new code for a feature that probably nobody has ever wanted yet
- GNOME bug 501365: dead code removed; fixed
- GNOME bug 403148: looking for some memory leaks
- GNOME bug 499301: refactor which probably isn’t interesting to any of you
- GNOME bug 133896: handle some X errors more gracefully
Elijah and Iain: I am thinking of making this entire blog licensed cc-by-sa. What say you? Anyone else?
The Metacity Journal bounds back to your screens! It’s been a busy couple of days; I think we’re about due an unstable release. Here’s a quick roundup of life around these parts:
- GNOME bug 474889 LONG KEY IS LONG: There is a particular GConf key which contained a small novel in the long description, and some of the translators asked for it to be shorter. We agreed on this in principle months ago, and then never actually did it. Sorry. Nostra culpa (or indeed mea culpa: Thomas was down to actually make the change).
- GNOME bug 112560: Sometimes Metacity grabs the keyboard, for example when you’re using alt-Tab, and then you might decide to stop doing that and do something else without actually finishing the alt-Tab. What if you let go of Tab without letting go of alt and then pressed f1? This is a basic fix for that case and, again, it should have gone in months ago but got lost. (Yesterday I did a sort of garbage collection pass over the bug list. I think I should do that more often.)
- GNOME bug 496054: a reported crash in obscure circumstances in the menu code, when you only have a single workspace; we couldn’t replicate it but it’s no bad thing to check you’re not passing nulls around, which was the obvious fix.
- GNOME bug 501362: Kjartan Maraas reported a typo where the “y” coordinate was checked twice in themes instead of the “x” and the “y” both once; Martin Meyer provided a patch(!).
Things people are actively talking about (as ever, feel free to jump into the conversation):
- GNOME bug 480954: random crash, probably not reproducible, dup finder finds nothing; I doubt this is going to lead anywhere
- GNOME bug 502644: someone wants a way to turn off wireframe as such, rather than minimise and drag wireframes separately.
- GNOME bug 500279 (the theme parser refactor): Andrea Cimitan says it interacts in bad ways with Iain’s compositor, so we are putting 500279 on hold until the compositor is sorted.
- GNOME bug 502635: Should it be the responsibility of the window manager to tell your IM client to set you “away” when you make another window fullscreen, since you can’t use the IM client?
Translation: Spanish, Czech, Belarusian, Brazilian Portuguese, and Galician have been worked on recently. Thank you all for contributing and reading and using.
Till next time…
Photo: The Peacock, St Albans. Photo: Gary Houston, public domain.
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.