GNOME Bugzilla – Bug 482354
gtk_window_present() causes full applications to move workspaces
Last modified: 2008-12-21 20:18:57 UTC
This bug is being forwarded from https://bugzilla.redhat.com/show_bug.cgi?id=307581 Essentially, Metacity seems to move all windows that call gtk_window_present to the current workspace. This is the right thing for dialogs, but at least some users of multiple workspaces feel it is a regression for applications such as Firefox. One suggested fix is to for dialog windows, move them to the current workspace, but for application windows, move the user to them. Or alternatively, just have the task list flash for them.
One case to consider is clicking on the panel launcher for a single instance app; is flashing on the tasklist good enough in that case? Surely a quick fix is to just do the task list flash for window type normal, though, not worth blocking that on figuring out every single case.
Created attachment 97443 [details] [review] don't warp window type NORMAL
Created attachment 97451 [details] [review] don't warp window type NORMAL, but do demand attention This patch causes the window to demand attention instead of warping workspaces.
A refinement we were tossing around is to key off transient parent, i.e. warp windows if necessary to stick them to their parent. This solve the "gnome-terminal prefs dialog" case since gnome-terminal changes the transient parent (I think it does, anyway). Also e.g. if you present() a dialog on another space, but with a transient parent, then the transient parent would demand attention.
One key thing to keep in mind is that NORMAL windows aren't special here. If they shouldn't move then e.g. UTILITY windows shouldn't move either. Like Havoc pointed out in comment 4, dialogs /are/ special because they're often reused and given a different transient parent, so figuring out whether dialogs should move will take some extra checking, but I think most of the time windows shouldn't change workspaces at all. Another thought is it might make sense to jump the user to the workspace things are happening on if the user time isn't newer than the event (i.e. extend focus stealing prevention to workspaces). This might be confusing to the user though.
See also: bug #128380
Um, I agree with Ray that we definitely shouldn't special case to normal. What I don't quite understand or follow is why we need any special cases based on window type at all. I'm open to changing whether windows should switch workspaces as part of a _NET_ACTIVE_WINDOW message, but I'm a little confused as to why dialogs might not follow the same rules as other windows (unless you're thinking of apps being "launched" again, but that case is already handled separately nowadays). Anyway, a bit of history... You can see part of this in bug 128380, that Colin referenced. Lubos suggested our behavior was wrong, both on wm-spec-list and then in the bug report. Havoc didn't see any reason to not change it. The bug sat for a long time, then I finally found some time to do it. Somehow, NOBODY complained during all the beta releases and release candidates during the development cycle and didn't point out a nasty regression until after the stable release. Utterly annoying. At that point, I started re-analyzing and most seemed to agree we should revert. I pointed out that I'd do so on wm-spec-list, and made a bit of a fool of myself as I tried to argue why. Lubos actually did figure out that our regression was due to a separate additional bug, namely that we ignored startup-notification sequences sent for existing windows instead of treating such windows as being re-launched (much later fixed; see bug 347515). I kind of got the point even at the time, but it didn't fully sink in. And besides, we were in the stable cycle and I thought we needed a fix for the subsequent (.1?) release quickly, we had lots of loud screaming users, I didn't have time to implement the real fix (and it hadn't sunk in to me that it would be the real fix quite yet), and having made a fool of myself already I for some reason boneheadedly stuck to my points of the argument and tried to find the quickest way to extract us out of the mess. Within the next year or so, I slowly started to understand that Lubos was right (and that I had made even more of a fool of myself than I realized at the time, though that's a tangential point). Since then I've thought several times about fixing things as Lubos suggested, but I worry each time a bit about there being other little bugs causing nasty regressions that no one will report until well after .0 is out and having screaming users again and playing a big twiddle-the-default-endlessly game. *shrug* So that's where things stand. But what I don't understand is why you guys suggest dialogs (or any other window type) should be special? I'd think we wouldn't want to switch workspaces for any window for _NET_ACTIVE_WINDOW messages. (Which would also mean changing the code slightly, since a new _NET_STARTUP_ID message uses the same code, and we do want that case to cause a workspace switch for the window.)
Well, I guess dialogs are special because apps often gtk_widget_hide()/gtk_widget_show() them instead of destroying them and recreating them. If you have two gedit instances up, on separate workspaces, and you to go Edit > Preferences on one of them, click close and then go Edit > Preferences on the other one, you'd expect the dialog to show up on the workspace you're currently on. (I don't know if gedit does hide()/show(), so I don't know if it's a real example)
But gtk_widget_hide() and gtk_widget_show() doesn't invoke gtk_window_present() or otherwise issue a _NET_ACTIVE_WINDOW message, right? The gtk_widget_hide()/gtk_widget_show() just basically result in a withdrawal & mapping of the window, which metacity naturally treats like a "launch" of the application. And, as you point out, launches should mean the window gets placed on the current workspace.
So, looking at gedit it does: if (GTK_WINDOW (parent) != gtk_window_get_transient_for (GTK_WINDOW (preferences_dialog))) { gtk_window_set_transient_for (GTK_WINDOW (preferences_dialog), GTK_WINDOW (parent)); } gtk_window_present (GTK_WINDOW (preferences_dialog)); in its gedit_show_preferences_dialog function.
> I'm open to changing whether windows should switch workspaces as part of a _NET_ACTIVE_WINDOW message, In an old bug here http://bugzilla.gnome.org/show_bug.cgi?id=166379#c17 referenced in the wm-spec-list thread, Bryan when given a choice between windows coming to you or vice versa, said that windows should come to you. Matthias also used an analogy of king/servant in another bug. I think there is actually a more fundamental rationale here, more simply stated: users of multiple workspaces want to feel in control. So when they put something somewhere, they want it to stay there. I would venture to guess that Bryan had something of this "feeling of control" in mind behind the choice. But we actually have a 3rd option, partially implemented in this bug, which just causes a pulsing tasklist entry, rather than moving the window or moving the user. I do believe that the pulsing entry is sufficient. So I agree with you in that there is no reason to special case NORMAL. My main concern in all of this is the single workspace case. We should focus on getting the right experience there. Fundamentally, I'm not sure we're ever going to be able to make multiple workspaces a perfect experience. There are too many odd interactions. It's worth noting that neither major consumer operating system offered workspaces until Apple's latest release. And even in Leopard, it's a special mode that you have to explicitly enter.
Does anyone have a test case for something that would break with the current patch? I.e. a program which has a non-NORMAL window upon which it then calls gtk_window_present()?
Created attachment 98755 [details] [review] updated patch to key off whether or not the window is transient
Elijah - as historical background, the reason for sudden interest / noticing the behavior here is that Colin fixed Firefox to do the startup notification stuff, so there was suddenly a popular situation (opening a web link) that revealed metacity's behavior. I really don't know the right fix, the only thing I've argued fairly strongly is that any hacks/fixes should be to metacity, rather than removing the fixes from Firefox or trying to subvert the WM in Firefox.
Here is a bug related to this change opened about Pidgin: https://bugzilla.redhat.com/show_bug.cgi?id=371161 It feels to me that if people want Pidgin to have its current behavior, it would make the most sense to have it explicitly ask for it by calling gdk_x11_window_move_to_current_desktop. Opinions? I am realizing though just how hard it is to change behaviors like this across the whole Linux stack. One possibility is to punt and change the Firefox patch to do if (using_multiple_workspaces()) return; though I'm not totally sure how to implement that, because unfortunately GNOME defaults to having 4 workspaces.
PLEASE don't start hacking apps to work around the problem here... we need to 1) work out exactly what is supposed to happen 2) put in the spec what the WM and apps do and only then 3) modify the apps to follow the spec. If we start hacking the apps ad hoc, it just makes things much worse. The only thing apps should do for now is what's already in the specs (_NET_ACTIVE_WINDOW, startup notification). Step 1 is just document the desired behaviors for a bunch of concrete cases. Here are some so far: A. Launching a new app from the menus B. Launching a single-instance app, say Thunderbird or Rhythmbox, from the menus; when it's already running C. Opening a new tab in firefox after clicking a link in another app D. Launching an already-running control panel, say the Background Properties dialog E. Xchat button blinks in the task list due to someone talking to me, and I click on it F. I click the Pidgin tray icon G. I click the Rhythmbox tray icon H. I choose Preferences from the gnome-terminal or GEdit menu, and the prefs dialog is already open on another workspace Anyone want to risk being the first to document a proposal for those cases? In our current "box" our options in each case would be 1) blink task list button, if any (dialogs and tray-icon-having things don't have one) 2) warp to current workspace 3) change workspace to wherever the window is Thinking outside our box, we could add features such as workspace affinity (i.e. a given app is always stuck to a given workspace and never moves). Gets complicated fast.
I think we've always said that workspaces are grandfathered crack. They cause a whole lot of extra headaches for not much benefit. As to the patch as it stands: * please compare window->xtransient_for against None, rather than using it as a boolean * I would rather we didn't use the throwaway boolean located_on_workspace, particularly since it means that the side of the short-circuit boolean which always gets evaluated is the most expensive one. I don't see that it gains us anything, anyway. * Is there some reason we are not using meta_window_set_demands_attention () ? (And as we're already discussing, are there any reasons window_activate () might actually want to warp a window instead of attentioning it or leaving it be?)
Crazy suggestion: The reason these nasty bugs exist is because there is no GUniqueApp/GtkUnique/whatever library in the platform like KUniqueApp. In particular, I think it may be that _NET_ACTIVE_WINDOW is being used to simulate an "application launch", working around the fact that there's no good/easy way to really launch something properly. In cases where it is intended that the window opening be treated like an application launch, the window should be brought to the workspace where the user is. To assist with that, we really ought to get a real startup-notification launch so that we can recognize it as such. In cases of an already existing window that isn't being treated as being relaunched (e.g. the xchat or firefox cases), we want to switch to the workspace where the application is. In the special case of an application switching a transient's parent, we should detect that and warp the transient to where the parent is (i.e. we should force the constraint that transients are on the same workspace as the parent, always; we're probably pretty close to that already in the code). I believe this handles all the cases Havoc outlines, though I'm a little unsure of F & G, not having been much of a user of tray icons.
Oh, and by the way: If apps are relying on _NET_ACTIVE_WINDOW to bring application windows to the current workspace, then they are broken under KDE and likely all non-gnome window managers (I believe Lubos said that metacity was the only WM a few years ago that would warp windows to the current workspace in response to _NET_ACTIVE_WINDOW messages.) I'm thinking that Lubos was right about how to treat that message, and that our original usage just got misapplied as a hack to simulate launches...and since we didn't have real API for unique-application-launching we got stuck supporting the buggy behavior to make the workarounds work.
My proposal: A. Launching a new app from the menus * Appears on the workspace from which the application was originally started B. Launching a single-instance app, say Thunderbird or Rhythmbox, from the menus; when it's already running * Focuses the app if it's on current workspace; otherwise causes a pulsing indicator in the task list C. Opening a new tab in firefox after clicking a link in another app * Same as above. D. Launching an already-running control panel, say the Background Properties dialog * Same as above. E. Xchat button blinks in the task list due to someone talking to me, and I click on it * Takes you to the workspace Xchat is on and focuses it F. I click the Pidgin tray icon * I believe Pidgin is a special case here as I mentioned above; basically people want it to warp to current workspace. G. I click the Rhythmbox tray icon * Acts like clicking on a pulsing tray item; clicking takes you to the workspace with Rhythmbox H. I choose Preferences from the gnome-terminal or GEdit menu, and the prefs dialog is already open on another workspace * Prefs dialog disappears from other workspace, appears on current From Elijah's comments I think we largely agree, except I'm not sure I understand this comment: "In cases where it is intended that the window opening be treated like an application launch, the window should be brought to the workspace where the user is. " Are you saying if I start Eclipse on Workspace 1, then switch to Workspace 2, Eclipse should appear on 2?
Created attachment 99786 [details] [review] focus/DEMANDS_ATTENTION handling, take 3 This patch should address Thomas' review concerns.
Notes on the above patch: Added an _internal version of set_demands_attention which takes the current workspace in order to pass the same workspace argument that window_activate receives. Not sure it's necessary but I wanted to be safe. Also, the set_demands_attention function did not handle the case where the window was on another workspace; this patch makes it treat windows not on the current workspace as obscured; most of the noise at the bottom of the patch is reindenting for that flow change. Finally, I did not attempt to create a constraint for forcing transients to match their parents in this patch; it seems logically separate. Should we open a new bug? I noticed also that gnome-terminal, in addition to gedit, does the hide/reparent/show trick.
Delicious...tasty...cookie! Waiting for the reviewer of this patch...
Sorry, have been insanely busy; hoping to get it reviewed tomorrow.
Okay, some thoughts. a) Most of my concerns from earlier have been addressed. b) I don't think it's necessary to check other_window->workspace == window->workspace any more, since we already know whether the window's on another workspace. c) I was trying each action A to H in sequence with and without the patch, and typing up the results here, and then Flash crashed my browser (more fool me) so I'm not going to do it again just yet. I will try again later (unless one of you can affirm that it all does what it says on the tin).
(In reply to comment #20) > B. Launching a single-instance app, say Thunderbird or Rhythmbox, from the > menus; when it's already running > * Focuses the app if it's on current workspace; otherwise causes a pulsing > indicator in the task list > > C. Opening a new tab in firefox after clicking a link in another app > * Same as above. I found it pretty handy that Firefox 2 merely pulsed its window list button when I clicked a link in another app and didn't also focus, even if I was on the same workspace as it, since it enabled me to open multiple links in tabs (f.e. while browsing through a set of email messages) before switching to Firefox to browse them instead of having to repeatedly switch back and forth between the application I am using and the browser. And note that Firefox implements this behavior within the application by opening links in new tabs in the background by default for all users, so while browsing a web page (f.e. a set of messages in a webmail client, the home page of a news site, or a set of search results) you can open a bunch of links on the page in new tabs without having to repeatedly switch back and forth between the page you are browsing and the tabs you open. Thus I would suggest that opening a new tab in Firefox via clicking a link in another app should pulse the window list button but not focus the application, even if Firefox is on the current workspace, so that opening a link in a new tab from another application behaves like opening a link in a new tab within Firefox, i.e. it doesn't require you to immediately context switch to that new tab. On the other hand, it would make sense to focus Firefox when a user's preference is to open links in an existing tab, since then the user isn't employing multiple tabs to queue a set of pages for browsing and is likely to want to browse the link immediately.
"Thus I would suggest that opening a new tab in Firefox via clicking a link in another app should pulse the window list button but not focus the application, even if Firefox is on the current workspace" First, this is not the way Firefox works on other platforms. And for good reason: I submit that it is extremely confusing for non-powerusers. If you click on a link, you want to see that link. "And note that Firefox implements this behavior within the application by opening links in new tabs in the background by default for all users" Firefox's tab behavior is only relevant if the link requested a new window. What you will need to get in the habit of doing in this power-user open-many-links case is to right-click and do "Open in new tab". This is what Firefox users on other platforms do, and we are bringing Linux into line.
(In reply to comment #27) > First, this is not the way Firefox works on other platforms. > > And for good reason: I submit that it is extremely confusing for > non-powerusers. If you click on a link, you want to see that link. I agree, but I think non-power-users are also less likely to be using tabs. > Firefox's tab behavior is only relevant if the link requested a new window. > What you will need to get in the habit of doing in this power-user > open-many-links case is to right-click and do "Open in new tab". This is what > Firefox users on other platforms do, and we are bringing Linux into line. That's exactly what I do within Firefox (or rather I middle-click or do the equivalent with the keyboard), but that option is not available in other applications. My point about Firefox's behavior is that it is optimized for both regular users who don't use tabs much and power users who do, because it opens pages in the foreground when users target them to the current tab (as regular users generally do) but in the background when users target them to a new tab (which mostly power users do), and that this is not so different from what users may expect when they open links from other applications. Nevertheless, I recognize that the goal is to expand the usage of tabs to regular users, which is why Firefox opens links in new tabs by default, and thus it's difficult to differentiate between "link from other application opens in new tab because that's the default" and "link from other application opens in new tab because the user wants it to". So perhaps the optimal solution is to do what Mac OS X does, which is to focus the browser by default but define a modifier that suppresses that behavior. For Mac OS X, the modifier is the Command key, and when you Command-click a link (whether within Safari or in another application) it loads the link into a new Safari window (by default) or a new tab (if so configured) in the background. For GNOME, this could also be a modifier key (f.e. Control), a middle click, or both.
(In reply to comment #28) > > So perhaps the optimal solution is to do what Mac OS X does, which is to focus > the browser by default but define a modifier that suppresses that behavior. > For Mac OS X, the modifier is the Command key, and when you Command-click a > link (whether within Safari or in another application) it loads the link into a > new Safari window (by default) or a new tab (if so configured) in the > background. > > For GNOME, this could also be a modifier key (f.e. Control), a middle click, or > both. > I'm fine with that idea. The basic idea would be that e.g. gnome.url_show would also take a GdkEvent to determine modifier state, or something like that? I'm assuming the OS X platform "show URL" API has this, or maybe it just finds the current event internally, but that would be a bit ugly. In any case though, discussion for implementation of this functionality should be a new bug; let's open that when we figure out where to put it.
(In reply to comment #28) > For GNOME, this could also be a modifier key (f.e. Control), a middle click, > or both. Note: within Firefox both Ctrl-click and middle click open links in a new background tab by default, as does the keyboard shortcut Ctrl-Enter. > I'm assuming the OS X platform "show URL" API has this, or maybe it just > finds the current event internally, but that would be a bit ugly. I'm not sure how Mac OS X does it, although I've observed the behavior in a variety of Apple and third-party applications, including Mail and Colloquy. > In any case though, discussion for implementation of this functionality should > be a new bug; let's open that when we figure out where to put it. Sounds good.
Created attachment 104591 [details] [review] focus/DEMANDS_ATTENTION handling, take 4 Merged the patch up to the latest SVN. Also I simplified it because we didn't really need to go through the hoops of creating an _internal function.
Just a gentle reminder: this bug greatly affects Firefox 3 which is not too far behind GNOME 2.22 in terms of likely release date. If GNOME users are using an unpatched version of netacity and Firefox 3 (or Firefox 2 with startup notification support enabled), I expect there will be a flood of bugs to deal with. I understand GNOME 2.22 is out soon, but I feel this should be a priority to fix for 2.22, and hope one of the metacity developers cc'd on this bug can find time to review this.
I have been asked to get this in for the 2.22 freeze. I am okay with doing so. Syntatically the patch is fine, as I mentioned; semantically, this is a complicated issue and I don't fully understand all its ramifications. Havoc, Elijah, do you have any reasons why not? If not, I will check in to gnome-2-22 at lunchtime EST.
I'm aware of two regressions from this bug. First, the Pidgin issues from comment 15. Second, jrb mentioned that he had a Nautilus window showing ~ open on Workspace 1, and when double-clicking on the Home folder on the desktop, he got a pulsing taskbar. I'm not sure what's really expected here - do we want the window to warp? Or have two windows? The latter would seem to break the spatial mapping, but then again we have > 2 desktops.
So putting this in makes Firefox appear to behave correctly, but breaks Pidgin and Nautilus? I think if one of those is likely to be doing the right thing it isn't Firefox.
I wouldn't say it "breaks" either - calling them regressions is perhaps a bit much. Just that the behavior changed. Before the window warped to you; now you get a pulsing indicator on the taskbar. I believe we determined earlier that Firefox is doing the right thing.
I apologize for mostly disappearing during the 2.22 cycle; I should have been around to help fix this. Firefox is following the EWMH correctly, yes. The problem is that the EWMH doesn't have within its specification a message for what firefox wants to be done; the spec is simply not comprehensive enough yet. Lubos told me (private email) that he currently handles this in KWin with an application specific workaround fore firefox...and he thinks that the correct fix would involve EWMH changes. I think that's the sanest route. I do not like the proposed patch; it's just a hack that is going to break things (and keeping dialogs on the same workspace as their parent should be an enforced constraint, thus we need to handle it elsewhere). A hack specific for firefox as a short-term solution would be fine with me, but I think Lubos is right about the long term solution.
Can't Firefox be fixed with the current EWMH specification? Gedit is one application that behaves sanely with multiple workspaces, i.e. it opens a new window if there isn't one on the current workspace and a new tab in an already existing window if there is. Isn't that what Firefox also should be doing?
What is the suggested application specific workaround? Also, what would the new EWMH hint specify to do? Do we agree on the behaviors from comment 20?
(In reply to comment #38) > Can't Firefox be fixed with the current EWMH specification? > > Gedit is one application that behaves sanely with multiple workspaces, i.e. it > opens a new window if there isn't one on the current workspace and a new tab in > an already existing window if there is. Isn't that what Firefox also should be > doing? > I would like to chime in as a user. I keep one firefox window open in one workspace which is my firefox workspace. I would hate for firefox windows to start popping up in my other workspaces. This may not conform to some notions of correct application behavior based on whatever you base these things on, but it is how I use it, and how I like it. Please do not make firefox windows popup all over the place. Please. Or, and I know this is asking for a lot, leave me with the ability to configure this setting. I really like the way firefox 2 works (haven't tried 3 yet). I click a link and whenever I get around to it I can switch over to the firefox workspace and see what I clicked. And comments like #27 are very scary. They make me feel like the desktop experience I enjoy is being held hostage by people who don't care about the "use case" that I represent.
Does anyone know Lubos' email? If so, can we pull him into this discussion so that we have a similar design across both metacity and KWin?
Adding Lubos Lunak's email
Sorry, but I'm not going to take part in this discussion here. I don't have time read and analyze all this, and I have no idea about internal GNOME things like gtk_window_present(). If you think this problem is not GNOME-specific, please move and sum up the discussion to the wm-spec-list (so that also others can take part and it's not only Metacity+KWin). Thanks.
Lubos, from comment 37, it was mentioned that you had changed KWin to use a Firefox-specific workaround - can you point to the workaround? Has there been discussion of this on the wm list?
As far as I know, no and no. The only Firefox-specific workaround in KWin used to be turning off focus stealing prevention for it, and that has been already removed. I'm not aware of any Firefox problems with KWin (from bugreports, I don't use it myself).
1) For a moment I thought you meant you didn't use KWin yourself. :) 2) The Ubuntu folks have decided attachment 104591 [details] [review] is a decent fix and applied it downstream.
Ok, so let me collate the known fallout from this patch: 1) Pidgin buddy list no longer warps workspaces (but do get pulsing taskbar) 2) Opening ~ via desktop icon on one workspace, switching to another, then double-clicking on desktop icon again no longer warps window (but do get pulsing taskbar) 3) When task list is in "Show windows from all workspaces" mode, if a window is minimized on one, clicking on it on the other will no longer restore it Now I know at first any changes sound bad, but really none of the above strikes me as world-ending. 1) and 2) are behavior changes, but I would not say they cause the software to be unusable. Now 3) just plain does not work, it's a non-default configuration in a corner case, but still. One thing it is important to note is this issue differs between Metacity and KWin; for example: http://bugzilla.gnome.org/show_bug.cgi?id=522514 is one KDE user complaining that Pidgin *doesn't* have the workspace-warping behavior, in KDE. For that reason among others, despite the side effects I still think this patch is the right long term fix. I'd like to get 3) fixed - it seems like it would require a different WM/tasklist protocol? 1) and 2) could be done with the hide/show trick.
1) also happens with rhythmbox and its tray icon: make rb visible on #1, switch to workspace 2, click on the systray icon to make rb visible, nothing happens, click again and again and again until you notice something happened since an rb icon is blinking in the task list.
(In reply to comment #47) > Ok, so let me collate the known fallout from this patch: > > 1) Pidgin buddy list no longer warps workspaces (but do get pulsing taskbar) > 2) Opening ~ via desktop icon on one workspace, switching to another, then > double-clicking on desktop icon again no longer warps window (but do get > pulsing taskbar) > 3) When task list is in "Show windows from all workspaces" mode, if a window is > minimized on one, clicking on it on the other will no longer restore it Just some thoughts on issue 2): I get this behaviour for any location in the filesystem, not just for ~ via a desktop icon. If a user doesn't use the Window List, they will have no indication that anything has happened. The only result will be that no window appears. Window/file management just takes longer now. For example, dragging a file from window A (open on Workspace 1) to another window B (already open on Workspace 2), will now require the user to manually move a window from one Workspace to another. This, after double clicking on folder B, not seeing the window appear as expected, noticing that the Window LIst is pulsating, and then clicking on it.
> 3) When task list is in "Show windows from all workspaces" mode, if a window is > minimized on one, clicking on it on the other will no longer restore it> > Now I know at first any changes sound bad, but really none of the above strikes > Now 3) just plain does not work, it's a non-default configuration in a corner > case, but still. This was immediately apparent and incredibly annoying to me. My task list is set to 'show windows from all workspaces' and 'restore to current workspace'. One of the main advantages is that I can keep my IM windows minimize and pop them up on whatever desktop I happen to be on. Having to switch desktops is far more disruptive to my workflow, and having to hunt through desktops to figure out where a window first popped up (or alternately having to manually move them to the same one whenever a new one pops up) is enough that I've downgraded to metacity from the one that shipped with RHEL/CentOS 5.2.
I'm just a plain dumb Pidgin user, very frustrated by what I think is related to this issue. Not being much of a coder, I am not at all clear on what is being discussed here, nor what the resolution is, or might be. But in a nutshell, the problem is this: I used to be able to bring my Pidgin conversation window forward, by clicking on ANY active buddy in my buddy list, which might be in any workspace. But since Ubuntu Hardy Heron release, all that happens is that a taskbar item appears, requiring me to click that to activate the conservation window, When I do, I am then whisked off to the active workspace where that window lives. This is not the old behavior, and very annoying. As a user, I want my buddy list to bring the child windows to me, no matter which workspace that buddy list might be in at the time (often it's set to visible on all of them). The good folks at Pidgin feel this is a MetaCity issue, and this thread would seem to confirm that impression. Could one of you nice people clearly summarize the state of this issue for us? I will happily paste any responses back to the Pidgin forum on Nabble. Thanks much PS FYI: Here is where I first discussed the problem on the Pidgin/Nabble forum. http://www.nabble.com/Lost-workspace-function-with-Ubuntu-Hardy-tt18352855.html
I may well be losing track after so many comments and so much time, so I hope someone else can clarify this a bit better, but as I understand it the problem is: Suppose you have an application which has two windows A and B, and you put them in different workspaces, and then you do something in A which the application thinks means you want to stop looking at A and start looking at B. For example: * You're using Pidgin. You click on someone in your buddy list (A) and Pidgin brings up their tab in the chat window (B). * You're using Ephy or Firefox or some other browser. You click on a link in some other program entirely (A) which the current page wants to load in the browser (B). * You run an upgrade utility such as synaptic in window A; as part of an upgrade it must kill another program which has window B up on another workspace; you have unsaved work in window B; window B's application puts up a "Do you want to save your work?" dialogue. What should happen? (1) The window B is raised and gets focus, and you get warped to the workspace it's on, or (2) The window B is raised and gets focus, and moved to the workspace you're currently looking at, or (3) The window B gets the attention hint (causing it to flash on the taskbar) and stays where it is, or (4) nothing happens, or (...) maybe there are others. The behaviour people seem to want in Firefox is (1). The behaviour I think you're asking for in Pidgin is (2). The behaviour you seem to be getting is (3). We originally did (2), as you know, and in fact upstream Metacity-- here!-- still does. Last autumn, Ubuntu changed this to (3) using patch 104591 below, for the reasons given in comment 0: it doesn't work well with Firefox and similar programs. Here upstream, we are still arguing over it. It seems that the downstream solution wasn't too popular, either. Does that make sense as a summing up of the state of play? I have some ideas about where we can go from here, too, but I haven't included them here. (It's "Metacity", btw, rhyming with "opacity".)
Actually, my synaptic example is something else; forget that bit.
My summary on the Pidgin issue is: the way Pidgin behaves here is different between Metacity and KWin. If they believe it's part of their app's workflow, we should figure out a way to support it specifically. My suggestion is to keep this patch, and change pidgin to do the hide/show pair to force the window to move workspaces. I can write that patch.
(In reply to comment #52) > The behaviour people seem to want in Firefox is (1). The behaviour I think > you're asking for in Pidgin is (2). The behaviour you seem to be getting is > (3). We originally did (2), as you know, and in fact upstream Metacity-- > here!-- still does. Last autumn, Ubuntu changed this to (3) using patch 104591 [edit] > below, for the reasons given in comment 0: it doesn't work well with Firefox > and similar programs. Here upstream, we are still arguing over it. It seems > that the downstream solution wasn't too popular, either. To elaborate a bit further... Fedora has been using an older patch for much longer, being that Colin Walters originated the patch for Fedora. Fedora 8 and 9 have been using variations of the patch over time as we've been trying to beg this into the metacity tree, and I blogged about this fix which got it extra attention in an attempt to find someone to shepherd it into GNOME 2.22, and subsequently led Ubuntu's awareness of the patch which they then added to their packages. I'm told openSUSE has it too, but I haven't verified this. As an upstream Firefox developer, based on the sheer volume of reports I noticed regarding this issue prior to my blogging, and the lack of reports after, I would say that nearly EVERY distro of relevance currently ships with the patch or a variant of it. On the Fedora side of things, while we've heard the occasional complaint about Pidgin's new behavior, they have been few and far in between. Over the course of about a year, the complaints about Pidgin don't even come close to the volume of complaints we received about what Firefox did during the few days before Colin created and patched our local metacity. I strongly think the reason you don't hear more is because just about every distro have patched it quickly because users were complaining. Loudly. I think that since distros are already carrying this patch because it seems to please users more than the current upstream behavior, there really is no argument to be had. At the least: take it for feedback. If you receive an overwhelmingly bad response to this patch, which I doubt, feel free to revert it.
Good point. I think if RH and Ubuntu have been carrying the patch for a while with success, that's a compelling argument to switch (annoyed Pidgin users notwithstanding, and if Colin or someone can patch Pidgin that will be wonderful).
The focus of this thread seems to be mostly on the patch's effect on Firefox and Pidgen, so I'd like to bring attention again about how this patch makes spatial Nautilus behave much differently than before. And point out that a lack of complaints from Ubuntu users doesn't mean much here because most of them don't use spatial Nautilus (browser is default). Trying to open a folder which is already open on another workspace merely gets a throbbing indicator in the Window List that the user must click on to be taken to that folder. Or worse, if the user doesn't use a Window List, literally nothing at all happens. No folder and no indication that the folder is already open somewhere else. Would it be possible to make an exception for Nautilus here?
I'd rather patch Nautilus.
/me is an upstream Pidgin developer, but not particularly well versed in the X11 window management architecture. What would the patch to Pidgin/Nautilus look like? I don't see why every application should be patched to deal with this, unless they were already broken. From what I understand, Pidgin calls gtk_window_present(), which is documented as follows: "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. ... This function should be used when the user tries to open a window that's already open." -- http://library.gnome.org/devel/gtk/stable/GtkWindow.html#gtk-window-present How is that not appropriate for the Pidgin case? The user is trying to open a conversation window that's already open, so we call gtk_window_present() on it. I'd say the invariant here is that doing something on a workspace should not move you to another workspace, directly or indirectly. A workspace is a project area. If I'm working with an object (window) in that area, I want it to come to me, not move me to the project where I was last using that object. Thus, regarding comment #52's options, I would say that presenting a window should move it to the current workspace. This is the old behavior and was clearly expected by the GTK+ folks when they wrote the docs for gtk_window_present(). It's also expected by Pidgin users, myself included. The problem the patch tries to address seems to be with Firefox. When does Firefox present windows? Is it only when opening a URL from another application? In that case, I'd say if I'm on workspace X with application window A and I click a link, I want that to come up on workspace X, even if Firefox is already open on workspace Y. Rather than move Firefox or warp me to it or give me a flashing task bar, I'd argue the correct behavior is to open a new Firefox window on workspace X, which would then get focused. The existing Firefox window on workspace Y would be left alone.
Hi, nice to get your input! I agree that gtk_window_present() is apparently the problem. I think the docs for it give the WM quite enormous latitude as to what to do when it's called, though; quoting them doesn't really answer the question of what to do to make everyone happiest. I think this was never a problem until people started using tabbed browsing. Firefox now defaults to opening new stuff in a new tab. That's okay unless your browser is on another window, in which case you won't see it. Maybe we need to ask the GTK folks what they intended, and to split gtk_window_present() into pidgin-ish and firefox-ish versions.
As another pidgin developer I would like to make it clear that pidgin (as an application) has made *no* policy decisions as to what should or should not be happening when the user clicks the buddy list entry for someone and the conversation window is created. All we care about is that the conversation window is created and displayed to the user. How the window manager decides to interpret that display request (gtk_window_present() in this case) is entirely up to the window manager. As far as I'm concerned the description of the _NET_ACTIVE_WINDOW message in the EWMH and the description of what gtk_window_present does is exactly correct and should not be made more specific (that is to specify a window management behaviour). The issue here, to my mind at least, is that there are rather clearly two different valid user desires for how applications should work and picking just one is difficult if not impossible to do for all applications.
(In reply to comment #61) > The issue here, to my mind at least, is that there are rather clearly two > different valid user desires for how applications should work and picking just > one is difficult if not impossible to do for all applications. This metacity developer would like to concur entirely-- thanks for a good and concise statement of what this whole argument is about. (Also, note that we haven't actually applied the patch upstream. RH and Ubuntu have, and possibly some other distros, but we haven't. We need to decide whether we should, or whether we should do something else; if the consensus is to do something else, this will also require advocacy on downstream trackers.)
(Upstream == here, I mean, not upstream from here, because there isn't an upstream from here, obviously.)
<<I'd say the invariant here is that doing something on a workspace should not move you to another workspace, directly or indirectly. A workspace is a project area. If I'm working with an object (window) in that area, I want it to come to me, not move me to the project where I was last using that object. >> As one the "annoyed Pidgin users" in question, who has tried to nudge a few to come together here for the good of humanity, I concur with the above. If an application manages windows, I expect their child windows to be fetched to me, in whatever workspace i've decided should contain the parent window (the buddy list, in this case). Not that it matters much, as i know you devs are dedicated to finding the best solution for all concerned, but I'd like to point out that I have not found another Pidgin user yet who does not agree with me about this. In my experience, vast numbers of users don't comment about things they assume is their fault, the fault of their platform, or a problem others are already aware of, and will be fixed, so they don't bother complaining about it. I think if users were explicitly asked about it, most would express annoyance with this change in Pidgin behavior, regardless of the underlying cause. Finally, on behalf of all the plain dumb users who never thank you guys adequately for all that you do for us, let me thank you for them. Were it up to me, there would be an international thank you day for all you FOSS developers :)
Another pidgin dev here. I agree with Etan and Thomas that the behaviour of _NET_ACTIVE_WINDOW and hence gtk_window_present() is intentionally vague and should not overly specify window management. With regards to patching pidgin to use the hide/show hack, I think most pidgin devs would agree that we should not be actively trying to dictate/circumvent window manager behaviour. Doing so with one window manager may have unintended consequences on others. With that said, I do plan on adding signals in the necessary places so that I can implement a plugin to do the hide/show hack for user's that prefer that behavior. With respect to metacity, do any of the devs have opinions on making the behavior configurable? Personally I don't have a strong opinion either way, though I agree with Richard that switching the user's workspace would be undesirable. I am expecting complaints from a number of my user's (at work), hence my desire to implement said hooks and plugin prior to our F9 upgrade.
(In reply to comment #65) > With respect to metacity, do any of the devs have opinions on making the > behavior configurable? I think this would be a bad thing, because the two major behaviours are currently pretty much "what you want for Firefox" and "what you want for Pidgin". I assume there are people who use both (heck, I have both open myself every minute of every day), so it's a bit of a kludge to ask people to pick one over the other.
Right, you do not want the config setting: (*) Break firefox ( ) Break Pidgin That's basically what the config setting would be. Bad bad bad times evil. There needs to be one configuration which works for all apps, and which is the default. (At which point, having a config setting is pretty pointless.) Just skimming this whole thread, I get the impression that a separate request is needed for "present this already-open window" and "have this already-open window ask for attention" perhaps.
Havoc: Which of your proposed "present" and "attention" options are you ascribing to which application? Is the firefox scenario just clicked links opening new tabs? (I'm not exactly sure I followed it all.) Also, I think there has been too much of a focus on this as being a two-horse race and it isn't. The issue here isn't "pidgin wants one thing and firefox wants another" it isn't even "users want pidgin to do one thing firefox to do another". This is much broader than that if you ask me. Personally I use a window manager which by default doesn't move me or the windows around and just alerts me that they want me, so I can react to them when I'm ready (either by pulling or being pulled). But, as I think is being rather clearly shown in this ticket and the linked KDE ticket, etc. users aren't all that consistent and while I understand the metacity position of attempting for simplicity I think in this case that is unlikely to find a solution that actually works for everyone. It will cause at least some people some annoyance and they will either adapt or switch. Unfortunately, I really think the 'right' answer here is the ever-popular Do-What-I-Mean-This-Time which is to say "know when I want the given window to pull me and when I want it to come to me and do that for me". I just don't think that is going to fall across nice enough lines for a default (non-configurable) policy to be able to implement.
I was just using the "pidgin" and "firefox" names to try to get across the different possibilities here. Really, there is no good answer; the spec is ambiguous, and people have implemented it in two different ways, and they're both equally right. You're right to say that configurability is the answer, but not configurability chosen by the user. The user a) doesn't give a damn about a million fiddly options like this, and b) might be running some programs which deserve one and some which deserve another. Rather, it's configurability chosen by the client which we should be going for. So, here is my concrete suggestion, which I'm happy to implement unless someone has an objection. The current spec for _NET_ACTIVE_WINDOW is: _NET_ACTIVE_WINDOW window = window to activate message_type = _NET_ACTIVE_WINDOW format = 32 data.l[0] = source indication data.l[1] = timestamp data.l[2] = requestor's currently active window, 0 if none other data.l[] elements = 0 I propose to add a new element: data.l[3] = request for how the window is activated. This is to be considered advisory. The window manager MAY take account of this in activating the window. Options not mutually exclusive may be ORed together. #define _NET_WM_MOVERESIZE_SIZE_UNKNOWN 0x00 /* 0 is to be used by legacy apps and those which don't care */ #define _NET_WM_MOVERESIZE_SIZE_WINDOW_TO_USERS_WORKSPACE 0x01 #define _NET_WM_MOVERESIZE_SIZE_USER_TO_WINDOWS_WORKSPACE 0x02 #define _NET_WM_MOVERESIZE_SIZE_DEMAND_ATTENTION 0x04 Your thoughts? The weekend's coming up, so I can try building something if there aren't any hidden crazinesses I missed.
Except they wouldn't be called MOVERESIZE_SIZE because I wouldn't be c&p'ing them from the EWMH. They would be called _NET_ACTIVE_WINDOW_ACTIVATE_UNKNOWN or something. *headslap*
From what I understand, the only complaints about the existing (upstream) behavior are with regard to Firefox opening URLs in new tabs. I maintain that this behavior is sub-optimal. I think changing this behavior to fit better with the concept of workspaces would solve the issue without needing to change window management specs and various applications.
Richard: What would you prefer Firefox to do in this case?
I covered this in comment #59, but I'll re-iterate: Firefox should open a new window on the current workspace with one tab with the URL I clicked. The existing window should stay where it is. If, however, I'm on the same workspace as an existing window, it should create a new tab in that window and present the window.
I agree with Richard's suggested behavior for Firefox--that would be awesome. And I suppose we could even do that in Pidgin, but something tells me users wouldn't like it. I think this is a pretty difficult problem, in general. Even looking at only Pidgin. If an IM window on a different workspace requests attention (e.g. you received an IM) the window should blink in the taskbar. If the user clicks on the icon in the taskbar what should happen? Ideally the IM window should move to the current workspace. If your buddy list is on a different workspace and requests attention (e.g. someone requested permission to add you to their buddy list) the window should blink in the taskbar. If the user clicks on the icon in the taskbar what should happen? I don't think the buddy list should move to your current workspace. I think our buddy list window and IM window are basically the same type of window. And so it seems like it would be hard for a window manager to heuristically determine when it should move a window and when it should not. I think I agree with Thomas Thurman that it might be best to let the client decide what should happen to a window when it's activated. I'm not very familiar with how X and window managers work so I can't speak to whether the solution is good... but it seems reasonable. What would the 0x04 flag DEMAND_ATTENTION do?
Your suggestion is in fact more complicated than mine. There are three programs involved: A: the program which owns the summoning window B: the window manager C: the program which owns the summoned window. In the current case of Pidgin, pidgin is both program A and program C. In the case of Firefox, Firefox is C and the summoning application (Evolution or whatever it is) is A. A is already asking B to move the summoned window around. I am merely asking it to supply a little more information with its request. In the current state of things both upstream and downstream, and in my suggestion, C is barely involved. In your suggestion, we would need to define a new message which meant something like "The instruction you have just been sent out of band should be honoured by creating a new window on workspace (N) unless you already have one, in which case you should use that one". How this message would be generally useful and not an ad hoc sticking-plaster for this one case isn't clear to me. I am also wondering whether you realise how difficult it will be to get the Firefox devs to pay any attention to such a message. (In case any of the Pidgin devs reading this misread that: only under Richard's suggestion does program "C", which can be Pidgin or Firefox, have to do anything at all. I'm not saying, "Well, Firefox devs are ornery about accepting new messages, so let's put the burden on the Pidgin folks".)
Mark: DEMANDS_ATTENTION is the thing where a window tries to get your attention by flashing its frame and putting a pulsy thing in the taskbar even if it's on another workspace. The current state of play (I believe) is that Ubuntu and Fedora have patched their copies of Metacity to set DEMANDS_ATTENTION on the summoned window when the situation we're discussing comes up, rather than switching workspace or moving the window. So I thought it made sense to add that bit as well for completeness, but maybe it's a bit over the top.
To add my two cents: I truly believe that there's a usecase for every kind of behavior and I would love to have the power to choose the appropriate behavior on a case per case basis. Sometimes I like to click on links and have Firefox accumulate tabs on another workspace without bothering me (a bit of flashing is ok for indicating that something happened). In other cases I'd like a new window on the current workspace etc. There's not one true solution and window managers and applications should offer the possibility to change their behavior on demand.
Arthur: The thing I'm trying to understand is how you, and the others who say you want this solely under user control, actually want this controlled. I run both Firefox and Pidgin all the time every day. Suppose within one hour I both want to open a link in Firefox, and to double-click a name in Pidgin. What would you have me do to tell the system these two cases are different? Do you think I should hold down some kind of modifier key, or do you think I should scurry off to system preferences and change some kind of checkbox before I clicked, only to change it back again the next time I wanted to click a link in Firefox? I cannot understand how this could reasonably be under user control. And I cannot understand why having this under user control is a better solution than having it under application control, since the application will always know what kind of application it is and the user will often not.
Thomas: Ideally the application has a sensible default behavior depending on what kind of application it is. For the user to adjust it based on her current need there could be an entry in the window menu, controlled by the window manager (like the existing entries always on top, always on visible workspace etc.).
Arthur: Okay, so you're not disputing that this is something the window manager should ask the application about? That makes sense to me, then. (The part about adding a menu option is an enhancement request and would need a separate ticket.)
Thomas: No, I'm not disputing that at all, the application should be queried for a sensible default setting. I'm only saying that people will ask for different behaviors depending on their usage.
This entire thread raises issues I am sure are important. I just wanted to bring windows forward in one very specific context. I am having trouble understanding why that requires all of this generalization of the window manager, but I guess it raises many other considerations I cannot appreciate. Still, if I double click an active parent or primary window of an application, such as the buddy list, doesn't that application have priority over what the window manager does with the requested child? I am not interested in incoming messages, notifications, or anything else. Just bringing my conversations to me in my current workspace, when I click on the buddy list, which can presumably scream at its children, and only its childre, and tell them to come home this minute! (in this workspace). Is that really the same issue as all these others that you guys are discussing here? Or are you exploring the much deeper zen of all this?
tech: When you double-click the buddy list, the window manager *is* what is raising the requested child: it's the window manager's job to manage windows.
And the Buddy list (Pidgin) cannot decide for itself, what its buddy list object does when it gets a click event? The windows manager is already off and running, regardless of what the active window wants to do next? Perhaps my brief experience in windows programming was misleading (as well as painful), but in that tortured world, I could easily hook that event message, kill all further processing of the message, and do as I pleased with my children. That does not seem to be the case here.
tech: Please listen to what I'm saying: the window manager is what is raising the requested window. Pidgin can decide for itself all it wants. In fact, that's what my suggestion in comment 69 is to allow it to do: to give it the choice, to "do as it pleases", as you say. But once it's decided what to do with the window, it then needs to ask the window manager to do so. It can't do so by itself, because it's not a window manager. That's just how X works. With respect, you're not adding very much to this conversation here; you've come along and told us, eighty comments into the discussion, that you can't understand what we're talking about, told us you don't understand how X works, told us how we should fix it anyway, and finally suggested a mechanism for solving the problem under Microsoft Windows. If you would like me to explain how X works, I'm happy to do so on the blog-- please ask away. If you have any suggestions which haven't already been covered, I would love to hear them. Otherwise I'd like to keep this bug on-topic, so in all politeness can we end this sub-thread?
I understand the desire behind the proposed wm-spec change (and I may even agree with the idea, I haven't thought it all through yet) but the proposed names are absolutely not acceptable (I think names along the lines of _MOVE_WINDOW and _MOVE_USER are better, workspaces are the current model and not at all really relevant to the idea at hand). That being said I'm not sure I think encoding that sort of information in the request is reasonable, or more to the point I think it 'solves' the one issue we seem not to be having here, namely, applications that want a specific response to the message in spite of the wm configured default and does absolutely nothing to help solve the issue that we seem to have been discussing, namely, figuring out a good system by which to have all windows do the right thing. (An issue where I fall squarely into the pick a default and let the user override it on a per-application, per-window, per-workspace, per-what-have-you basis camp.) I know that pidgin doesn't care what happens when the window is requested. Does firefox/evolution/$LAUNCHER care?
Just wanted to comment on #73 - that's the behaviour I've had for years using Galeon. A new window is created if there isn't one on the current desktop; subsequent tabs are created in that window. The behaviour described in #40: "I click a link and whenever I get around to it I can switch over to the firefox workspace and see what I clicked." doesn't sound like something that should be using gtk_window_present() at all. Not sure how typical a user I am but I would expect behaviour like #73 if browser.tabs.loadInBackground was set to know, and #40 if set to yes. Frankly, this seems like this patch breaks the expectation set by the GTK+ docs (along the Window List applet, to cite just one example) for the sake of a single application (Firefox) that probably shouldn't be using it the way it is. Looking back, the API reference has had the same description of gtk_window_present since 2.0.0: "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." Warping the window to the current desktop falls within that definition just dandy; simply demanding attention does *NOT*. So how is this patch not a regression? Flashing the task list isn't presenting the window to the user, afterall. Seems to me this is something to be fixed in Firefox if their users don't like the current behaviour.
(In reply to comment #86) > I understand the desire behind the proposed wm-spec change (and I may even > agree with the idea, I haven't thought it all through yet) but the proposed > names are absolutely not acceptable (I think names along the lines of > _MOVE_WINDOW and _MOVE_USER are better, workspaces are the current model and > not at all really relevant to the idea at hand). Yes, you're right: EWMH doesn't talk about workspaces at all. However, what we call workspaces are called desktops in EWMH, so we could use that instead, or we could just leave it out. I don't really mind: the names aren't as important as the idea. > That being said I'm not sure I think encoding that sort of information in the > request is reasonable, or more to the point I think it 'solves' the one issue > we seem not to be having here, namely, applications that want a specific > response to the message in spite of the wm configured default and does > absolutely nothing to help solve the issue that we seem to have been > discussing, namely, figuring out a good system by which to have all windows do > the right thing. The question, I believe, is: who knows what the right thing is? I don't believe the WM does, unless someone tells it. The user *may*, and if the user is one of you folks s/he *will*, but mostly they CBA with this sort of nonsense. They want it just to work. The application *always* knows. > (An issue where I fall squarely into the pick a default and > let the user override it on a per-application, per-window, per-workspace, > per-what-have-you basis camp.) But that's the one thing you're not going to get out of Metacity, because you've just described window matching, which we have a policy of not touching. You want devilspie (or a different WM).
@thomas, Sorry for cluttering up the thread with dumb questions or . Your blog didn't, and doesn't seem conducive to such discussion. There was no obvious place to have such a sidebar, and I didn't know it was necessary to find one. I didn't for a moment suggest how to "fix it." I was simply responding to your brief clarification in a further attempt to understand, not realizing that was a step beyond my place. I apologize. Thanks again for the efforts.
FWIW, the firefox bug is https://bugzilla.mozilla.org/show_bug.cgi?id=388664.
(In reply to comment #89) > Sorry for cluttering up the thread with dumb questions or . Your blog didn't, > and doesn't seem conducive to such discussion. I'm not trying to put you in your place. I'm only another user who happens to maintain this thing. I was merely saying that the subthread wasn't being conducive to getting the bug fixed. The blog is http://blogs.gnome.org/metacity/ , not my own personal blog.
http://blogs.gnome.org/metacity/2008/07/22/dona-nobis-pacem/ now posted.
Just want to throw in my two cents: The notification approach obviously fails when you don't use any window list applet...
In my opinion, this is clearly a situation where the application needs to decide, and this is already possible without the patch, as far as I know. For the typical Pidgin case, it seems to work fine. For Firefox, I see 4 use cases (all assuming a Firefox window is already open on another workspace): * Open new window on current workspace and focus it That's the way I prefer, as I don't want web pages regarding unrelated projects in the same window. That's also how gedit works. * Open new window on current workspace in the background This is useful if you want to look at the page some time later, possibly open multiple links in a short time. * Open new tab in existing window and move window to current workspace This makes sense if you use a single Firefox window for everything and you want to look at the opened page immediately. * Open new tab in existing window and demand attention This makes sense if you use a single Firefox window for everything and you want to look at the page some time later, possibly open multiple links in a short time. If Firefox wants to support all these use cases, they should have the following two options in the preference dialog: * Use shared browser window / Use single window for all web pages I'd recommend to default this to off, not sure whether that's what most users want, though. * Load new pages in the background This should clearly default to off, as it sounds like a power-user feature.
(In reply to comment #75) > Your suggestion is in fact more complicated than mine. There are three > programs involved: > > A: the program which owns the summoning window > B: the window manager > C: the program which owns the summoned window. > > In the current case of Pidgin, pidgin is both program A and program C. In the > case of Firefox, Firefox is C and the summoning application (Evolution or > whatever it is) is A. > > A is already asking B to move the summoned window around. I am merely asking > it to supply a little more information with its request. In the current state > of things both upstream and downstream, and in my suggestion, C is barely > involved. Thomas, I'm not a pidgin dev, but I don't quite understand why A should decide (or even suggest) where the new window should be summoned? For example, if I click a link in Evolution, and this link is passed to Firefox, I don't see a reason why Evolution, and not Firefox should be the program which decides what to do next. Thus, I don't think "A" is actually involved. "C" should be a program that finds out which worspace is active, and then decides whether to open a new window or re-use an existing one (and what to do with it in the second case).
Sorry for not replying to any specific comments but I honestly couldn't get through all of them. First I'd like to point out that from a user's point of view a document IS the application. We complicated a lot of things by allowing applications to have more than one document open in a single window (instead of improving the taskbar, we started adding tabs that do the same thing but somehow we feel they do it better). What a user would expect (I can't prove it but that's what I get from observing first time computer users - as opposed to first time Linux users or first time Firefox 3 users or whatever) is that clicking a document icon opens a new window to view/edit that document. Clicking the icon again should not launch _yet_ another window (unless we are able to merge changesets for just any file format) but instead move the user to the document they were editing (if a user put the window on desktop 3 then chances are there is a set of other documents open there that provide a _context_ for editing the file, by moving windows we destroy that context). Opening a "single instance" app again should just warp the user to the app (for the very same reasons). In fact each file-app combination should be considered a "single instance" or "unique" window (so I can't open the very same file twice and overwrite my own changes). As "demanding attention" was designed to prevent focus stealing, its main use is for apps that are not in our current focus. User get used to it by learning they can ignore the flashing windows until they are done with the current task and get back to them later. Stuff like IM apps teach you to ignore the flashing buttons until you are not busy with your work - kind of like how people exposed to Internet advertising developed the "banner blindness." Therefore no _action_ of the user should result in just a tiny flashing button (if I click, that's my action, if an IRC client opens an incoming link from a friend, that's not my action). In other words: * all windows should be treated equally (with the exception of transient windows that should always switch workspaces following their parents) * all automatic activations should result in a flashing taskbar * all manual ("interactive") activations should result in the user seeing the window (and moving the user to the window if necessary) * bonus: add some kind of short animation so the user is aware that a workspace switch occurred (ideally that would be panning the viewport to the the new desktop but that's not how metacity handles workspaces) Some special cases: * rhythmbox, pidgin, gajim etc. tray icons These are just broken by design. I can't help but visualize myself trying to explain the concept of disappearing windows to my father. I think his first reaction would be "doesn't the minimize icon do the same?" Broken or not, clicking the icon should be considered "manual action" and thus result in the window being visible (and warping the user to the workspace the window is at - even if previously hidden).
(In reply to comment #95) > Thomas, I'm not a pidgin dev, but I don't quite understand why A should decide > (or even suggest) where the new window should be summoned? > > For example, if I click a link in Evolution, and this link is passed to > Firefox, I don't see a reason why Evolution, and not Firefox should be the > program which decides what to do next. It's possible that the best solution is that Firefox should be the program which makes this decision. But *at present* Firefox is barely involved, whereas Evo is sending us a request to move Firefox, and this request could include more information. (It's calling a particular GTK function, and the change would merely be to make it call a similar one with an extra argument.) If this causes Firefox to move, there's no big deal from Firefox's point of view. It would be possible to get Firefox involved in the decision if we decided that was best, but that would require making up a whole new kind of message and writing code to get Firefox to accept it, which it doesn't at present. Then we'd also have the long process of getting the Firefox maintainers to accept the patch. I wasn't *necessarily* saying in comment 75 that having Evo make the decision was the ideal solution. Perhaps it is or perhaps it isn't. I *was* saying that it's far and away the simplest.
(In reply to comment #96) > Sorry for not replying to any specific comments but I honestly couldn't get > through all of them. First I'd like to point out that from a user's point of > view a document IS the application. > > We complicated a lot of things by allowing applications to have more than one > document open in a single window (instead of improving the taskbar, we started > adding tabs that do the same thing but somehow we feel they do it better). The concept of the taskbar itself is broken. I usually have about 10 windows open at the same time. No taskbar can resonable represent this amount of windows. There isn't sufficient screenspace to permanently list the titles of all 10 windows. > As "demanding attention" was designed to prevent focus stealing, its main use > is for apps that are not in our current focus. User get used to it by learning > they can ignore the flashing windows until they are done with the current task > and get back to them later. Stuff like IM apps teach you to ignore the flashing > buttons until you are not busy with your work - kind of like how people exposed > to Internet advertising developed the "banner blindness." Therefore no _action_ > of the user should result in just a tiny flashing button (if I click, that's my > action, if an IRC client opens an incoming link from a friend, that's not my > action). Definitely.
(In reply to comment #97) > (In reply to comment #95) > > Thomas, I'm not a pidgin dev, but I don't quite understand why A should decide > > (or even suggest) where the new window should be summoned? > > > > For example, if I click a link in Evolution, and this link is passed to > > Firefox, I don't see a reason why Evolution, and not Firefox should be the > > program which decides what to do next. > > It's possible that the best solution is that Firefox should be the program > which makes this decision. But *at present* Firefox is barely involved, > whereas Evo is sending us a request to move Firefox, and this request could > include more information. (It's calling a particular GTK function, and the > change would merely be to make it call a similar one with an extra argument.) Unless you refer to something else than gtk_window_present() function, I think you're wrong. Because Firefox is making this call, not Evolution. > I wasn't *necessarily* saying in comment 75 that having Evo make the decision > was the ideal solution. Perhaps it is or perhaps it isn't. I *was* saying > that it's far and away the simplest. See this Firefox bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=388664 . The reason why I believe Firefox should be making the decision is fairly simple and obvious: if I have five applications open, and I click links in four of them, I expect the browser be consistent, and act sistematically. I doubt that would be possible if we allow other applications to tell it what to do. Also, if this behaviour would be configurable, I'd expect to perform that configuration work once, in the target app, instead of many times in each calling application. (In reply to comment #98) Mathias, I think this is kinda off-topic here, but anyway, you can always use a larger taskbar, or use alt-tab. And you can of course disable taskbar anytime you think it doesn't satisfy your needs anymore. E.g. I have 13 windows open ATM, and I can clearly know what's happenning in each of them.
Whoops, I pasted the link in a wrong place. Sorry. :(
(In reply to comment #98) > The concept of the taskbar itself is broken. I usually have about 10 windows > open at the same time. No taskbar can resonable represent this amount of > windows. There isn't sufficient screenspace to permanently list the titles of > all 10 windows. Sure but instead of inventing some general solution to the problem we work around the broken functionality in thousands of places. Having 20 tabs in a tiny IM chat window is no better than having 20 buttons in the taskbar while taking roughly the same amount of vertical space away.
(In reply to comment #99) > Unless you refer to something else than gtk_window_present() function, I think > you're wrong. Because Firefox is making this call, not Evolution. It is? I must have been confused. Sorry. Then my previous comments, including the one about the change to the EWMH, make no sense.
(In reply to comment #102) > (In reply to comment #99) > > Unless you refer to something else than gtk_window_present() function, I think > > you're wrong. Because Firefox is making this call, not Evolution. > > It is? I must have been confused. Sorry. Then my previous comments, > including the one about the change to the EWMH, make no sense. See this Firefox bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=388664 .
I totally missed comment #38 until comment #94 repeated it. GEdit already does the right thing here, so we should just kill this bug report and ask Firefox to do the same thing as GEdit.
(In reply to comment #96) > Clicking the icon again should not launch _yet_ another window (unless we are > able to merge changesets for just any file format) but instead move the user to > the document they were editing (if a user put the window on desktop 3 then > chances are there is a set of other documents open there that provide a > _context_ for editing the file, by moving windows we destroy that context). Just to add another viewpoint, I'm not so sure about this. By doing an action that opens something, the user signals that he wants a certain window now, in the context of the current workspace - if the user wanted the old context, he could just switch to the workspace the window was on. By preserving an old context, we make it harder to switch to new contexts. Say a spatial nautilus folder, if a user has that folder open on a certain workspace it's a clear indication that at one point what the user was doing with that window was relevant to the task the user did there, and there's certainly a good probability that that folder may become useful there again. But that the user tries to open that folder on another workspace is a clear hint that the window is required for what the user wants to do right now, switching the workspace instead of bringing the window to the user just means that the user has to switch it manually to the workspace that contains his current task, and the same should he ever need it on the first workspace again. That said, I admit to having some problems, like xchat-gnome moving from workspace to workspace when using its tray icon, which annoyed me to no end, so I see your point. I solved it for me by not using the tray icon and manually switching to the proper workspace instead. Otherwise,I agree with your post. (and with comment #94) Workspaces are difficult things, if only they weren't so useful :-/
Created attachment 115108 [details] [review] patch to fix "show all workspaces" mode in tasklist This patch fixes the regression #3 relating to the (non-default) tasklist mode; it's for libwnck but I'm attaching here since it's really part of this bug.
Hi, there is a lot of discussion here now and I want to determine where we are concretely. My understanding is that we can apply the patch as is now. Is that correct or is there still technical disagreement?
(In reply to comment #20) > My proposal: > > A. Launching a new app from the menus > * Appears on the workspace from which the application was originally started > > B. Launching a single-instance app, say Thunderbird or Rhythmbox, from the > menus; when it's already running > * Focuses the app if it's on current workspace; otherwise causes a pulsing > indicator in the task list > > C. Opening a new tab in firefox after clicking a link in another app > * Same as above. I often find myself opening more than one link from a mail at a time. If the wm would pop firefox for each link I open from my mail, I would injustly hate firefox. Please, just pulse no matter which workspace. After all, it would be more consistent this way since the current desktop isn't special (usually, for me personally, is a coincidence that the source of a link might be in the same desktop). > D. Launching an already-running control panel, say the Background Properties > dialog > * Same as above. > > E. Xchat button blinks in the task list due to someone talking to me, and I > click on it > * Takes you to the workspace Xchat is on and focuses it > > F. I click the Pidgin tray icon > * I believe Pidgin is a special case here as I mentioned above; basically > people want it to warp to current workspace. I believe that pidgin is somewhat broken from this PoV and its developers should fix the behaviour as they like (although I suspect they could cause grief for their users). I say it's broken since it doesn't behave the same way on KDE as it does on GNOME, so I suspect they nevere relly decided HOW THEY want it to behave. > G. I click the Rhythmbox tray icon > * Acts like clicking on a pulsing tray item; clicking takes you to the > workspace with Rhythmbox > > H. I choose Preferences from the gnome-terminal or GEdit menu, and the prefs > dialog is already open on another workspace > * Prefs dialog disappears from other workspace, appears on current I agree with the rest of the proposal, although I don't know if any existant apps might break due to these changes.
(In reply to comment #88) > The question, I believe, is: who knows what the right thing is? I don't > believe the WM does, unless someone tells it. The user *may*, and if the user > is one of you folks s/he *will*, but mostly they CBA with this sort of > nonsense. They want it just to work. The application *always* knows. And my point is that quite often the application *knows* that it doesn't care. Which still leaves the wm needing to decide, which still leaves us with the core issue here which is that neither of the two policies is clearly more correct. > > (An issue where I fall squarely into the pick a default and > > let the user override it on a per-application, per-window, per-workspace, > > per-what-have-you basis camp.) > > But that's the one thing you're not going to get out of Metacity, because > you've just described window matching, which we have a policy of not touching. > You want devilspie (or a different WM). Agreed. I am fully aware that metacity doesn't touch window matching, and that is perfectly fine. I wasn't suggesting metacity start doing that. I was merely pointing out that, as far as I am able to reason this out, window matching is the only really reasonable way to handle this situation. (And personally I do not use metacity, or Gnome, for reasons like this. I mean no insult to anyone or any projects, I am merely stating a fact.)
(In reply to comment #108) > (In reply to comment #20) > > My proposal: <snip> > > F. I click the Pidgin tray icon > > * I believe Pidgin is a special case here as I mentioned above; basically > > people want it to warp to current workspace. > > I believe that pidgin is somewhat broken from this PoV and its developers > should fix the behaviour as they like (although I suspect they could cause > grief for their users). I say it's broken since it doesn't behave the same way > on KDE as it does on GNOME, so I suspect they nevere relly decided HOW THEY > want it to behave. We (the pidgin developers) have decided that we do not care how the pidgin window behaves when requested, only that it do something. We (intentionally) leave the decision about what focusing/drawing attention to the window means for the user in their environment. The issue here is that a number of users rather clearly want a different behaviour for pidgin then they do for other windows, and it is for this reason that I have repeatedly said that I do not believe a single policy decision will satisfy people. Side-note: Unless something specific about pidgin comes up again I am going to remove myself from this discussion as I do not believe I have anything more of use to provide on this issue in general. I do not use the environment involved and cannot meaningfully discuss what the people who do want or believe more than I already have. I wish you all good luck in sorting this out.
Looking from a user PoV, I think: 1) Dialog Windows - Metacity should bring those to the user's current workspace, so the user is always aware some ongoing process is asking for atention or had a problem. 2) Normal Windows - If there's a running instace of the application on another workspace, and the user asks, e.g., open a file, the application should remain on it's original workspace, and Metacity could notify him - I suggest a feedback mechanism using a similar concept as the currently used for switching workspaces (as it's always present if Metacity is running, doesn't depend on a Gnome's taskbar/pager, and doesn't suffer from excess of opened windows). Then, glow the wireframe+icon for window on the other workspace (even better with future compositor, were a real thumbnail of the window can be shown), and then let the user click the switcher to go the workspace were the running instance is. So, in the proposed scenario, if a link is clicked and Firefox, that is running in another workspace, opens a new tab for it, the user is notified that something changed on other workspace, the Firefox icon+thumbnail window is shown highlighted, and the user is given the option to switch there or just keep working on the current workspace (now having enough feedback that his action - "open link" - had a response). A solution like that would be more document-centric, as opposed to window-centric, and I guess this workflow is non-disruptive, intuitive enough for users already familiar with the workspace concept. If the user doesn't use more than one workspace, he would not have a running instance on another workspace anyway, as it implies to switch workspaces first, so won't be bothered with Metacity notifications. I hope my proposal is valuable, it's something I've been minding from some time - unfortunely, I don't know Metacity's code enough to implement it.
*** Bug 551367 has been marked as a duplicate of this bug. ***
Some users state that for spatial Nautilus, the current policy (i.e. only show up as urgent in the taskbar) is a regression. It was due to bug 166379 which seems to contain a huge discussion as well. Assuming there is no final agreement, and for multiple applications it makes sense to have different policies, we may want to add a general user preference for “what to do with windows that request to be presented”, and maybe even a per-application preference through GConf [or devilspie?]. At runtime, these preferences could be wrapped into a window hint that is read by the WM. If it's rejected, we should at least use the behavior that has causes the least complaints averaged over all users of all applications, even those who do not (know how to) use Bugzilla ;). Did anybody make user statistics on that topic?
Created attachment 120873 [details] Shell script to open a URL strictly in a new firefox tab on the current workspace If anyone's interested, I've gotten around this problem in firefox's case by writing a simple shell script that strictly opens a given url in a new tab on the curret workspace, even if that means opening a new window. It depends on wmctrl for finding/activating windows.
After much careful thought and discussion, I am minded to: * make presenting a window generally equivalent to setting needs_attention and: * I am unconvinced that the user should be warped to the workspace instead when the window is transient (see below), but if you can convince me of this last point, I'll put that in and: * (later, and only possibly) add a hint to _NET_ACTIVE_WINDOW to allow apps to hint that they want some other behaviour. because: * I don't think the current (summoning) behaviour is good because people put things on workspaces for their own reasons and don't expect them to jump around * I don't think in general that warping to a window is good because it will cause focus stealing * There is no particular problem with two X calls having the same result.
Nobody's objected, so I've committed patch 104591: http://svn.gnome.org/viewvc/metacity?rev=4060&view=rev I think this is an improvement, and if anyone has a problem with it, that'll be a new bug :) FIXED.
Thomas > what's the effect of your patch on Nautilus in spatial mode ? See the ubuntu bug about that : https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/213432