July 2008 – …for the adult in you

Compositor command-line switches

It seems, from reading blogs and forums, that many people like the idea of using Metacity’s compositor but are scared of changing the deep magic of gconf. In addition, there is nothing in the “–help” text to show that we have a compositor at all. Therefore, I propose a new switch to override the current gconf setting for the compositor, which will display in “–help”, and for symmetry another switch to turn it off again.

I am not sure whether –compositor and –no-compositor, or –composite and –no-composite, would be better names.

What do you think? Tell us at GNOME bug 545323.

How to get backtraces from a window manager

This may sound obvious, but I only just thought of it.

Suppose you make a change to Metacity which causes it to segfault on startup. What you’d ordinarily do is to load it into gdb and have a look at what’s going on in the backtrace with the bt command. But you can’t do that, because it will keep Metacity suspended and so no new window manager will be spawned, and that means that you’ll be running without a window manager. You can get around the problem by sshing into your computer from elsewhere, or by running Xnest or similar, or by using a virtual machine. But here’s a much, much simpler way.

Firstly, create a file called test.gdb containing the text
run --replace bt

Then simply give the command
tthurman@haematite:metacity$ gdb src/metacity --batch -x test.gdb [Thread debugging using libthread_db enabled] [New Thread 0xb7131720 (LWP 16959)]

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7131720 (LWP 16959)] 0xb7943a6e in g_error_free () from /usr/lib/libglib-2.0.so.0 #0 0xb7943a6e in g_error_free () from /usr/lib/libglib-2.0.so.0 #1 0xb7943adc in g_clear_error () from /usr/lib/libglib-2.0.so.0 #2 0x080a70ba in meta_frame_style_draw (style=0x8119c78, widget=0x8122090, drawable=0x80f4e20, x_offset=0, y_offset=0, clip=0x0, fgeom=0xbfc67384, client_width=1365, client_height=718, title_layout=0x80e1850, text_height=17, button_states=0xbfc67784, mini_icon=0x8123418, icon=0x8123398) at ui/theme.c:4553 [...]#21 0xb79561e7 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #22 0x08070992 in main (argc=1, argv=0xbfc68514) at core/main.c:479 tthurman@haematite:metacity$

Easy as that.

If the user will not come to the window, the window shall come to the user

Suppose you have two workspaces, and a window on each one. You’re looking at window A, so clearly window B is offscreen. You click something on window A, and window A attempts to present window B to you. What does that mean?

Let’s have two concrete examples:

0x01: You’ve clicked a link in Pidgin’s buddy window, and it’s attempting to present the chat window to you.
0x02: You’ve clicked a link in Evolution, and it’s attempting to present Firefox to you.

In 0x01, you want to stop looking at the old workspace and look at the new one. But you don’t want the windows to move off their workspaces. You want everything to stay where it is.

This is the way upstream Metacity currently works throughout. However, since Firefox is a tabbed browser,((I know Firefox has had tabs since 2002)) people have been asking whether this is the wisest course all the time. In case 0x02 above, in the old days, the browser would just have launched a new window in your workspace. People don’t like that now, because they want all their tabs in the same window. But if the user gets shoved onto the workspace of the existing window and then we add a new tab, eventually they’ll close it and then wonder where their mail went. (At least, that’s how I understand their argument; perhaps I’m mistaken.) As a compromise, downstream Metacity has now been patched in Ubuntu, Fedora, and possibly other places to make the window demand attention when this happens (i.e. go pulsy on the taskbar).

So we have multiple options when this happens:

Bring the window to the user, always.
Bring the user to the window, always. (This is what we do now.)
Make the window demand attention– in other words, apply the downstream patch. This is not the path of least resistance, since judging by recent feedback it appears to really annoy anyone using, say, Pidgin.
Tell the target application to deal with it. This would mean that Firefox could open a new window if you were on a workspace where it had no windows open and open a new tab if you were on a workspace where it had one already. It would mean finding some way of dealing with windows that didn’t co-operate. It would also mean, alone among all these solutions, that we’d have to find a way of communicating with the target application.
Ask the summoning application to give us a hint as to which of these it would like. This is my (Thomas’s) favourite solution. It will need a change to the EWMH.

Things which are not solutions:

Allowing the user to pick one and then requiring them to stick with it. As Havoc said, this is basically giving them a choice between “break Pidgin” and “break Firefox”.
Window matching. We do not do window matching. We are not about to start for an issue as small as this. That’s what devilspie is for.

Want to join in the ~~argument~~ fun? Dive in at GNOME bug 482354. The water’s lovely.

Photo credit: rofanator.

2.23.55 released

Thanks to Elijah Newren and Thomas Thurman for improvements in this version.

Contrary to rumour, this release does not add tabbing to everything.

Display theme name in title bar of theme viewer (Thomas) (GNOME bug 430198)
Allow toggling of non-compositor effects (Thomas) (GNOME bug 92867)
Add some extra null checks (Thomas) (GNOME bug 422242)
Check for double-freeing at the time of workspace freeing (Elijah) (GNOME bug 361804)
Don’t generate log messages unless we’re logging (Thomas)
Two windows which don’t belong to any application can’t be considered to belong to the same application (Thomas)
Various tidyings (Thomas)

Translations
Yavor Doganov (bg), Gabor Kelemen (hu), Kjartan Maraas (nb), Matej Urbančič (sl), Daniel Nylander (sv), Theppitak Karoonboonyanan (th)