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.
I don’t know if Metacity is currently able to do this…
But isn’t it possible to implement the Firefox click behaviour?
People are already used to this!
For both Pidgin Chat and Firefox link in Evolution (the examples above):
Click with the left button: Bring window to user in current workspace.
Click with the middle button: Open tab in “other” workspace and demand attention.
Of course, if there are no Pidgin chat windows or Firefox windows already open,
they would be opened in the current workspace in both cases above.
@Camila: Hi, nice to have your input. I like your solution, because it has the benefit of consistency. I do think it’s pretty much the same as “ask the summoning application to give us a hint as to which of these it would like”: whether you summoned the window with the left or the middle mouse button is the business of the summoning application, and Metacity won’t have been paying attention. We only get involved when the summoning application calls us to present the window. But it may be that the summoning application can pass us a hint to tell us how to present the window, and in that case it could well be decided by which button you pressed.
Hey Thomas, if something tells Firefox to “open http://gnome.org/” is it possible for Firefox to detect if it has a window open on the current workspace?
If so it seems like you could “bring the window to the user, always” and Firefox could be changed to open a new window if it does not have one open on the current workspace. That wouldn’t require finding a way for the window manager to communicate with the application, would it?
I’m a bit confused, you say that what metacity is doing right now is bringing the user to the window, always. I’m unfortunately on Ubuntu Hardy and as such can neither check nor satisfactorily use workspaces, but I remember it the other way around, that it would bring the window to the user, always.
The way I remember how it used to work is this:
If I clicked an open nautilus folder (spatial), it would open and show that folder, moving it if necessary from another workspace to the current one. Now, it just blinks in the taskbar, and if I need that folder where I am (to move something in there for example), I manually need to move that folder to the current workspace.
If I wanted to play a certain song, I could click the rhythmbox tray icon and I would see the rb window, ready to be used. Now, it depends on whether I managed to remmeber hiding the window, if not I get the blinking thing again, have to go to another workspace to change the music, and then I opefully remember which workspace I was on and what I was doing.
And that was the way I liked it, personally. :)
I think the main problem is that people use workspaces in very different ways, by application or by task (or use radically different methods of determining tasks, which amounts to the same).
Some people have one firefox window on one workspace, and do not ever want to see another window on another workspace, because it is to them the “web” workspace. Other people have a programming workspace, or a doing research desktop, or a reading mail desktop, or similar things. If they want to read up on some api, or find bibliographical information on some paper, or read something referenced in the mail they’re reading evolution, they may not want to break with the task they are doing and have switch between workspaces all the time just to access both the other program and the web page they need.
This is not the same as preferreing tabbed browsing (since people might want to use tabs, and possibly even open in tabs instead of windows when possible) and still have the second behavior. I fear that this is a thing that will have to be ultimately decided by the user. gedit, for what it’s worth, iirc only allows the second behavior.
Anyway, more flexibility might certainly be a good idea, but I’m not sure the calling application will always know how to do it correctly… sure, it would work for pidgin, but I’m not sure every app that wants to present a link knows how I like to use my $BROWSER, and then we might get very inconsistent behavior between calling apps.
Sorry for ranting ^^;
> * Make the window demand attention– in other words, apply the downstream patch.
Thanks for pointing out, why Ubuntu’s Metacity doesn’t work for me anymore. I really started wondering, why it doesn’t Pidgin’s tray icon doesn’t show me the contact list anymore when clicking it. Now I know: I don’t have a window list applet in my panel, and therefore I don’t see this notification attempts!
Whatever solution you end up with (my favorite is “add hint to either raise or demand attention”) please please please don’t move any windows between workspaces. That’s really annoying and eventually you end up with all the windows in the same workspace (a taste of such failure is the “adding icons to notification area so that an application disappears or moves between desktops each time you click” trend popular among media players and IM apps).
This “bug” is merely a symptom of the lunacy that is multiple workspaces. (I’m only somewhat trolling.)
Let’s say you’re working on two things in parallel: writing an e-mail, and editing a document. What do you do to switch between them?
A: switch windows
B: switch tabs
C: switch workspaces
Or perhaps it’s a combination of the above! Isn’t that a bit much?
Here’s a bug that’s much more annoying to me: http://bugzilla.gnome.org/show_bug.cgi?id=319491
@Jack: I was going to say I couldn’t help you on bug 319491, and I can’t with my Metacity hat on, but with my FUSA hat on, perhaps it’s a dupe of bug 543913.