Know all men by these presents…

sheep  &  her lambI tried to discuss the gtk_window_present() problem earlier, but I only managed to confuse myself. So here’s an extra rundown; perhaps we can move towards solving it.

The problem is that there’s a call, gtk_window_present(), which is very vaguely specified:

Presents a window to the user. This may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user’s platform, window manager, and preferences.

There are at least four ways of dealing with this request.  I hope I can establish a consistent terminology for them here.  Suppose we are looking at workspace 1, and an application attempts to gtk_window_present() an existing window on workspace 2.  We can:

  • Summon: the window is moved to workspace 1, so now we’re looking at it.
  • Visit: the window stays still, but we move to workspace 2, so we’re looking at it.
  • Pulse: the window stays still, we stay on workspace 1, but we set “needs attention” so it pulses on the taskbar.
  • Nothing: we do nothing.  This is allowable, but I think we can discount it.

gtk_window_present() is implemented using _NET_ACTIVE_WINDOW, which according to its specification allows the WM to make the requested window active (which could mean either Summon or Visit), or Pulse, or Nothing.

Many applications use gtk_window_present(), and because of the vagueness of the spec, there’s no agreement on what they mean by it.  Three instances which have been identified are:

  • Firefox. If you click a link in your email program, it will summon your current browser.  If this is Firefox, and it’s appearing in a new tab, it will gtk_window_present().
  • Pidgin. If someone talks to you, it will gtk_window_present() the chat window.
  • Nautilus. If you use one window per directory, and you request a directory that is already open in another workspace, it will gtk_window_present() the window for that directory.

The disagreement extends even to what Metacity should do when asked to present windows in each of the cases above.  Here are some opinions; feel free to add your own in comments, or tell me where other people have asked for something, and I’ll update this:

  • Firefox: Kevin Downey says we want Pulse.
  • Pidgin: technicull says we want Summon. The devs themselves say they don’t care as long as it’s not Nothing.
  • Nautilus: I think we want Summon here.  David agrees.

Some things which Metacity should not do:

  • Decide which to do based on the application.  This is window matching, and thus a recipe for pain.
  • Add a switch somewhere.  As Havoc said, this boils down to asking “Do you want to break Firefox, or Pidgin?”  And many people (including me) run both.

When people complain about Metacity’s behaviour in this matter, it’s hard to tell whether they’re complaining about upstream or downstream Metacity.  Upstream Metacity does Summon in all cases.  Ubuntu has patched to do Pulse (except for dialogues, which do Summon), as has Fedora, and I believe SuSE has too.  As policy, we usually reconsider policy when several major distributions make the same change, and this means we should probably stop to consider what to do here.

It might be possible for the app itself to hint in the EWMH message which behaviour it wants, if it doesn’t want the default.  Patryk Zawadzki says that the behaviour should depend on the user’s action; if the user carried out some positive action to cause the gtk_window_present() (as in the Firefox case), it should result in Visit, but if it happened through some external event (as in the Pidgin case), it should always result in Pulse. Mathias Hasselmann concurs.  I think this seems a reasonable plan, but the distinction between events generated by the user and not is one which the app is best placed to make, and so we probably also need a hint here.  I’m happy to add hinting as a test; however, the default option will necessarily be “don’t care”, and therefore we will still have to choose a best option as default.

I think most applications may be happy with a default of Summon, and that a default of Pulse is at least better than Visit in most cases, but I’m entirely willing to be convinced otherwise.

What do you think?

Photo © jan glas, cc-by-nc-nd.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

27 thoughts on “Know all men by these presents…”

  1. I was following along quite nicely until an unexpected Move operation crept into your Summon/Visit/Pulse/Nothing enumeration. Perhaps you meant to s/Move/Summon/ ?

  2. I’ll continue with my persistence (same posted to the bug report):

    * if the activation is a result of user’s action (clicking a link, activating a desktop file, whatever), this should be hinted to Metacity and we should do Visit

    * in all other cases we should do Pulse (we don’t want to switch workspaces while the user is typing a document and someone yells at them over the IM)

  3. I disagree with Patris:

    When I’m reading mail or feeds, I go clicking on links I want to view, and continue reading mail until I’m done, then I go and see all those links. I don’t want my desktop to keep moving to another workspace all the time.

    I think Pulse is a pretty sane default for everything (or for everything but dialogs). If distros have patched it it is because users found moving applications very annoying.

  4. Emilio:

    When you click a link in Firefox it does not wait until you are done reading the current document. I see no reason why clicking a link in some other app should not behave in the same way. Keep in mind the application could omit the hint for middle-clicks (so it behaves exactly how Firefox does: left click opens in front, middle click in the background).

  5. My opinion…

    For spatial Nautilus : Always move the windows on the current workspace and give it the focus when opening a folder.

    For Pidgin when someone speak on a conversation window : Always pulse in the windows list if the conversation window do not have focus. If the window is on an other workspace, move it the current workspace and give it the focus when clicking on the pulsed button of the windows list.

    For Firefox when clicking on a link somewhere on an other application, if there is a Firefox window on the current workspace, open the link and give it the focus on the already present Firefox window. if there is no Firefox window on the current workspace, open the link on a brand new Firefox window on the current workspace and give it focus.

    Also, on a maybe not so related subject, if you are on workspace 1, you open pidgin, then you switch to workspace 2, you click on the pidgin icon on the notification area, you actually have to click twice to finally see the pidgin window (first click: it will hide the window from the workspace 1, second click: the pidgin window is shown on the workspace 2). I would expect to see the pidgin window on the current workspace at the first click regardless if the windows is already showed somewhere else. Same apply to others applications that use the notification area: Rhythmbox, Transmission, …

  6. I have forgot, I was using compiz… please note the following change to the “not so related subject” of my previous post.

    So, with metacity as the window manager, if Pidgin (Rhythmbox or Transmission behave the same) is open on a workspace other the the current and then, you click on it’s icon on the notification area, then you get a pulsing button on the window list and if you click on it, you are moved to the workspace where pidgin is actually open. It would better to move the window to the current workspace if the window is already showed somewhere else when you click on it’s icon on the notification area. No pulse button, no automatic workspace switching.

    It’s like, if I click on it, I want to see it right there, right now.

  7. @Screwtape: Sorry, fixed. I used that name originally in my notes before switching to “Summon”. So much for consistent terminology :/

    @Patrys: Updated (second-to-last paragraph). I think acting according to whether there was a user action or not is a fine idea, but it’s something the app will know and the WM won’t, and so this is where we need the hinting idea.

    @David: I’m glad to find someone agreeing with what I thought about Nautilus :) Are you suggesting in what you say about Pidgin that the window should be both moved *and* set needs_attention? With regards to Firefox, although your use case seems sensible, Metacity can’t control which of many windows Firefox brings up a link in, although it might be nice if we could. And the use of permanent notification area applets is a big long-standing mess, and isn’t consistent anywhere, and needs a whole separate blog post, which I was planning a while ago: thanks for the reminder.

  8. @David: Your second comment is an interesting idea, and involves a change to the whole design of “needs attention” with respect to workspaces. In my experience most users say that when they put a window on a workspace they would like it to remain there, but clearly not everyone agrees.

  9. @Thomas: To answer your question, yes but not in that order, I would say, “set needs_attention” if the window doesn’t have focus when someone speak to you *and* “move it” to the current workspace if it was present on an other workspace when user click on the pulsed button.

    Also, if someone want to jump to the workspace where the pidgin window is, the windows selector applet could always be used.

  10. If I click on a link that opens a new Firefox tab, I want visit, but Pulse is fine too. If someone msgs me on IM, I want Pulse. I was going to say that I never every would want Summon, but maybe moving that Nautilus window to this workspace wouldn’t be so bad…

    I am one of those users who put a window in a specific workspace with the natural expectation that it will *stay* there.

  11. The problem with Visit (and to some extent with pulse) is that it completely breaks what you are doing. If I need another window for whatever reason, and by accessing that window I’m moved to another workspace, then getting back to what I was doing before means I have to find the previous workspace again, which adds another context switch.

    Example: I’m working something and someone I already have an open conversation with IMs me. I click the pulsing window list entry and am taken somewhere else. I reply, and the other person takes some time to reply, so I decide to return to what I was doing. I switch workspaces and have to check most of them to see if they are where I was. I find it and start again, then the reply comes and the whole process starts again…

    I do know the “I placed the window, it should stay where it was!” feeling as well, for some applications. I solved that by going to these windows only by switching workspaces, not invoking them again, but this only works for some applications. One solution would be configurable application-specific behavior, but I agree that window matching is not something that metacity should do.

    I think this is a point that people won’t be able to decide on, since it depends greatly on the way people work, and having your windows work in a way that won’t fit your workflow is a pain (After three months, I had to learn how to recompile deb packages and remove patches because it annoyed me too much). I assume that a option is necessary here.

    The important thing is that it should not be a “break firefox” vs. “break everything else” option, but a “keep my current focus stable, if possible” vs. “Keep my working arrangement stable, if possible” (in intent, not option wording). Aside from that, a solution that works for most use cases and people should be possible.

    Here’s my idea:
    – Allow the user to select opening in foreground or background (solving the “open multiple links from mails then read all of them” use case that Emilio mentions in comment 3). Needs to be done in the applications, I guess. Middle click and context menu entries are ideas. I suggest defaulting to opening in the foreground as it’s easier to understand, especially for users who are not proficient with task bars and might not see the pulsing and thus think the application is broken.

    – Allow applications to specify a certain mode (Summon, Pulse, etc. in fore/background) if they really really know what’s appropriate.

    – Keep the focus stealing prevention, so that windows that open without direct user intervention open in the background.

    – Allow the user to choose a Summon or Visit mode. This solves the “Keep my windows where they are” workflow of Patryk and Marius, and the “Keep me where I am” workflow I describe above. This should also determine what happens when the user clicks a pulsing window list entry. I’d suggest defaulting to Summon, but wouldn’t mind either way – it’s a power user feature, so new users will first have to understand workspaces (which makes this hard to test in a classic usability study), and old users will already have an idea of what their preferred workflow is.

    The Problem is that this might be difficult to implement, especially as applications need to support it, and that it adds some complexity – one option, and a small addition to application interfaces (though one that is already familiar from browsers, where it works in a similar way).

  12. Like I already mentioned in my (duped) bug report, at least spatial Nautilus should always open folders on the workspace they are activated. If the folder happens to be already open in another workspace, move it to the current one (or make it visible on just those selected workspace, I don’t really care as long as it shows up!).

  13. Pulse is good!

    Even better is: Pulse, single-click to move to the workspace that has the window, Double-click to bring the darn window to my current workspace. (Personally, I would be double-clicking a lot if this were the case).

    I guess this requires cooperation from the window-list applet?

  14. Thomas: unless we choose to use middle-click instead of double-click, that should also work for menus (like the window list menu applet).

  15. I’m still thinking about it and I think that Spatial Nautius could open more than one window per directory but, only one per workspace.

    Also, right now, when a directory is open, it’s icon change to an “open state” icon. This should also be changed; the icon should change only when viewing it from a workspace where the folder is open. Other workspace would still see the normal icon.

    Use case 1: You have the same directory ~/Data open on workspace 1 and workspace 2. Each workspace have his own view on the directory (including: scrolling position, selected files, list of expanded sub-folders, …). You move the window from workspace 1 to workspace 2. Then, the window on workspace 2 is replaced with the one from workspace 1.

    With this kind of behavior, a notion of “Copy this window to workspace X” (Actually, there is only “Move window to workspace X) could be implemented on the window management system. I don’t think that the “Copy window to workspace X” would work with all applications but it does make sense for some. For such a think, applications would have to be adapted.

  16. See for an example of a bug resulting from Ubuntu’s patch of metacity.

    I’m strongly in favor of the GNOME default (Summon). It’s extremely frustrating to click on a notification icon and have basically nothing happen. Same for tomboy… select a note thats already open elsewhere and seemingly nothing happens.

    BTW — it’s easy enough to remove the patch from Ubuntu’s metacity to revert back to the GNOME default, but what about users of compiz?

  17. BTW — I like Wolki’s idea of allowing apps to specify the mode. Also, as clean and elegant as metacity’s options set is, as Wolki also suggests, this may warrant a “default” setting addition (Summon/Visit/Pulse).

  18. @Nicholas:

    I really think we need, as well as rethinking the default case, a way for an app to say “And actually what I mean by this is ‘summon’ or whatever”.

    (It’s not really much of my concern or business what Compiz does– it’s nothing to do with GNOME. If they want to change to be more like metacity, good for them. :) )

  19. By allowing apps to specify the behavior (as opposed to just “user interaction” versus “computer-generated event”) we will end up with zero consistency. I don’t think most users care about summoning if we choose to visit in case of user actions and just blink in other cases. Those who care would be free to change the default for “interactive” mode from visit to summon. An app that feels it needs to move a window between desktops should do it on its own and then raise it, not rely on the WM moving it automatically. The two apps that come to mind are Nautilus (where being able to open the same folder on two desktops would actually be useful) and Totem (that insists on having just one instance open for no apparent reason which often forces me to launch mplayer just to be able to compare two videos).

  20. This really ought to be a configurable setting, with a single configuration GUI for all apps. That is, you can change “gtk_window_present()” to “gtk_window_present(tag, default_behavior)” and keep a user-configurable table:

    app, tag, behavior
    pidgin, message window, pulse
    firefox, link opened from elsewhere, summon

    Otherwise, you end up with each developer choosing a default behavior, which is often inconsistent with other apps. Also, this way the developer doesn’t have implement a user-configurable setting, make an interface, keep state, etc.

  21. Well, it’s not a question of burden on the users vs. on the developers. The proposed “gtk_window_present(tag, default_behavior)” function keeps *both* in control:

    default_behavior – lets developers pick what they think is best.
    central configuration GUI to alter the behavior table – lets the users who are bothered by the default behavior pick whatever they prefer.

    I think everyone agrees that an over-reaching window-matching approach is a bad idea. Applications should have good defaults, and window matching should be used only to allow users to tweak things to their liking (but shouldn’t be required).

  22. Is there a way I can hack Pidgin to go back to the way it was? It infuriates me like no other that when I click the Pidgin tray icon, it does not bring up my buddy list. And when I click a blinking tray icon, it does not show the new IM.

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *