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

Ok commandos, you’ve been asking for it all week

Everyone seemed concerned about window previews in the alt-tab dialog…

20 minutes coding, 30 lines of code added, this composite lark is easy (yeah, right…). Not committed yet, a few bugs remain (note the glitches in the Gossip window corners and the terminal window doesn’t get previewed yet, and obviously the scaling), but I’m confident I’ll be committing it soon.

Changes since the last blog entry: Fix weird crashes at startup, correctly mark screens as having a composite manager, and do drawings on an idle function so that we can compact redraw operations.

To answer some questions that came up in the comments last time round:

* No, you don’t need 3D acceleration for this compositor, so cards with sucky GL will be able to use it. You will however need a good  and fast XRender implementation. I’m using the both the binary NVidia driver and the opensource Intel driver. The NVidia driver works well, the Intel one (as shipped by Gutsy) works ok, but CPU usage can get high. I’ve been told the Fiesty Intel driver is quite slow.

* Yes, we can have window previews :)

* When I talked about people wanting translucent windows, I meant more that people wanted some parts of windows to be able to be translucent, which is used for things like AWN and cairo-clock stuff. I don’t really see the point of windows which are all transparent (although I did see a friend using some photo editor on the Mac tonight that had translucent dialogs, seemed a bit weird though. . . )

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.

Metacity 2.20.1 is out

Metacity 2.20.1 is out, with some regression fixes and various other improvements.

Thanks to Alex Turner, Jens Granseuer, Owen Taylor, Federico Mena Quintero, and Elijah Newren for improvements in this release.

  • Fix markup parsing problems with long titles for the alt-tab popup (Alex) [#360274]
  • Fix memory leak in widget previewer (Jens) [#469682]
  • Don’t immediately unminimize an initially iconic window (Owen) [#491090]
  • Fix argument reversal breaking timestamp retreival and focus stealing prevention (Federico) [#488468]
  • Improve heuristic for focus stealing prevention with transients when no timestamp is available (Elijah) [#488468]

Translations
Djihed Afifi (ar), Metin Amiroff (az), Alexander Shopov (bg), Jordi Mallach (ca), David Lodge (en_GB), Jorge González (es), Iñaki Larrañaga Murgoitio (eu), Alastair McKinstry (ga), Ankit Patel (gu), Rajesh Ranjan (hi), “Last-Translator: auto\n” (hr), Changwoo Ryu (ko), Raivis Dejus (lv), Wouter Bolsterlee (nl), Gora Mohanty (or), ASB (pa), wadim dziedzic (pl), Og Maciel (pt_BR), Duarte Loreto (pt), Peter Tuhársky (sk), Maxim Dziumanenko (uk), Funda Wang (zh_CN)

2007-11-16: “Higher standards of elegance”

There was some discussion over the option on the window menu which controls the attribute known to the developers as “stick”. This makes the window follow you around when you move workspaces; it’s useful, for example, to keep a clock applet always in the corner. Some people think that the window menu should have two options for this, and some people think that that is a waste of space, and not elegant, and rather it should just have one option which toggles. In that case, however, it’s not very clear how to word it: someone has suggested “Always on current workspace”, but what does it mean when that’s turned off? “Never on current workspace”? “Sometimes on current workspace”? The Human Interface people were helpful here.

Speaking of human interfaces, apparently now if you select the High Contrast Inverse theme, Metacity colours certain icons on the window menu a tasteful shade of black on navy. I think we need to get to that soon before Trinny and Susannah track us down.

Some people on Launchpad would like to be able to resize by dragging using mouse buttons other than the standard ones, because they don’t have a middle button.

And Benjamin submitted a patch for the theme directories problem which (informally) looks good. Unless anything particularly odd shows up in it, it should go into the next release, expected some time early tomorrow morning Greenwich time.

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

2007-11-15: xterm, glib, api

xterm has a habit of padding the bottom of the screen in unsightly ways, apparently (your chronicler always uses gnome-terminal). It was suggested that this might be solvable in metacity, but it’s not at all clear how the details would work. (Finding the bugs where this was discussed before would be useful.) Havoc pointed out that xterm is as patchable as metacity is.

Benjamin Gramlich submitted another version of his well-written theme-finding patch, only to have Havoc suggest that g_get_system_data_dirs() would do a lot of the work for him; Benjamin is now away rewriting the patch in terms of that function.

Thomas deleted api.[ch] because it was never used.

Your comments and suggestions about any of these, or anything else related to window management, are welcomed. As the header now says:

There will be links to discussions, and you should feel free to dive in. We might link to Bugzilla discussions, discussions on the various downstream trackers such as launchpad, news coverage, or random blogs. (If you mention Metacity in your blog, we will get to hear about it, and we might link it and discuss what you say.)

Today in the blogosphere, Harsh shares how to turn off the window minimise animation using gconf-editor, Opera Omnia told us that Metacity was not at all outdated, and elsewhere there’s some more talk from people who are switching back to Metacity from the default window manager in Ubuntu Gutsy: László at length on why he’s doing so and Magpie on how to do it (I believe there are actually easier ways, but I’m not currently running Gutsy, so I don’t like to comment).

A development point release is planned for Sunday (but might happen on Saturday, depending on workload).

Photo: The Rat’s Castle, St Albans. Photo by Gary Houston, public domain.

Adventures in Compositation Land

As Thomas said, I’ve been working on hacking about with a compositor in Metacity recently. All I’ve really done is to take xcompmgr.c by Keith Packard and worked it into Metacity, so I’m not claiming that I really wrote the compositor, more massaged an already existing one into shape. The code is at http://svn.gnome.org/viewvc/metacity/branches/iains-blingtastic-bucket-o-bling/ and it seems to work reasonably well on my desktop (Nvidia), but not so well on the laptop (Intel), so you might be lucky. Its not perfectly stable, but I’ll track down the problems soon I’m sure. Everyone loves a screenshot:

With that out of the way, I thought I’d explain a little about compositing and what my plans are.

What is compositing anyway?

When people talk about compositing they seem to think about vibbly vindows, desktops laid out hendecagonally which spin around, fish swimming behind windows and eating windows and other stupid effects who’s only purpose is for you to play with in conferences so the people sitting behind you have something to watch instead of listen to the boring talk. These are all things made possible due to compositing, but they are byproducts if you will. You can only have the effects if you have compositing, but you don’t have to have the effects to have compositing. And it is this barebones compositor I’ve put into Metacity.

Compositing at its simplest is a program telling the Xserver not to draw the windows anymore because the program wants to do it instead. So now X doesn’t draw the window to the screen, but to a backing store pixmap which the compositor program then draws on the screen. It makes sense for this compositing program to be the window manager, because it already knows all about screens and displays and what window goes where when. . . etc, but it does not need to be (e.g. xcompmgr).

The trick is that when the compositor comes to draw the window’s backing pixmap to the screen it can really do whatever it wants with it. It can paint it backwards, or with a red tint, or just simply paint it normally to the screen. Compositors like Compiz draw the window onto GL textures and then are able to do 3D transforms on them. The compositor in Metacity just draws it to the screen using the XRender extension.

What can we do with a plain compositor?

Well, just because the windows aren’t rendered into a 3D scene doesn’t mean it isn’t useful. Metacity was a designed as a simple window manager that concentrated on managing windows well. Its design ethos doesn’t stretch to being configured in every minute detail. And in my opinion, a simple compositor based on XRender fits in well. Most people I have spoken to want two things from a compositor. They want translucent windows[1] and drop shadows.

What does the future hold?

All metacity’s compositor needs to do is draw windows to the screen and draw a drop shadow around them, and I think its doing that pretty well at the moment. There are some rendering glitches (mostly in dealing withTrans windows) and some crashes, but it is getting there. There are a few other things that the compositor could do but most of the usefulness of a compositor comes from when the programs running on the desktop start to become aware of the compositor’s presence. In the above screenshot the volume control OSD changes design when there is a compositor and draws itself in a translucent design and can fade in and out. The gnome-terminal switches to real transluceny when running on a composited desktop. I have a patch for Metacity that turns the alt-tab dialog translucent with a compositor

Metacity could use the presence of a compositor to do other tricks as well…the icons in the alt-tab dialog could be replaced with window previews (because we can get the backing store pixmap to use anywhere we want), Nautilus’ desktop could be completely transparent meaning we could stop having to draw a huge image on both the desktop window and on the root window and the task switcher could show a popup of the real window. The list is endless. Maybe when I’m feeling up to it I’ll write a “So you want your application to look cool when a compositor is running” tutorial type affair. Maybe. I might be busy.

[1] There are two types of translucent windows: windows which have some area painted with an alpha value (an example of this would be a translucent gnome-terminal, only the text area has an alpha value), and windows that are normally completely opaque but have had their opacity lowered somehow. The former is controlled by the program for artistic measure, the latter is controlled outside of the program and more for an effect (e.g. lower the opacity of all dialog windows to 75%) as it affects all the elements of the window (as well as the frame).

Internally the first type are called ARGB windows, and the second type are Trans windows. Currently the Metacity compositor supports both, but there is no way to set the opacity of the Trans windows. There maybe at some point, who knows?

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