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.
