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

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

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:


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.

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