GNOME Bugzilla – Bug 100470
Clicking on a window in the workspace list shouldn't raise it
Last modified: 2004-12-22 21:47:04 UTC
Clicking on a window in the workspace list raises it. I don't think it should. There was a discussion awhile back about whether moving a window in the workspace switcher should move it on the screen. As I recall, the outcome was that it shouldn't, since the workspace switcher is only supposed to switch workspaces. More the the point, it bugs me.
It does seem kind of pointless, I have to agree... not to mention confusing, as it only does it if you click on a window in your current workspace, but not if you click on a window in a different one. If anything, it might be more useful if the opposite was the case (so you could focus a window on a different workspace with a single click rather than two)... but that comes with its own problems, so probably best just not to do it at all :)
I generally agree, not sure this was deliberate.
*** Bug 126482 has been marked as a duplicate of this bug. ***
This (annoying) behaviour is still present in libwnck 2.4.0 (FC1)
libwnck/libwnck/window.c: /* Activate the window clicked on *only* if it is in the * current workspace. Otherwise, the default window * should be activated (but that's a job for the WM, not * for the pager, as it is focus mode dependent). */ if ((space == wnck_screen_get_active_workspace (pager->priv->screen)) && (pager->priv->drag_window)) wnck_window_activate (pager->priv->drag_window); Seems wnck_window sends a _NET_ACTIVE_WINDOW signal to the WM. Havoc or Elijah? It's either wnck or metacity that needs to change it's behavior. Changing to NEEDINFO
Ooh ooh! Can we really change that? I added the "space == wnck_screen..." portion of the logic in bug 124981 because I thought someone really did want this crazy behavior for at least the current workspace (I was unware of Calum's comments and that it apparently had been for just one workspace at some point). Nuking those three lines (eight when you count comments) will fix this bug, which would be nice. My main reasoning for hating this current "feature" is Fitts Law: I want to use the pager solely for switching workspaces. Having it used to also shuffle the stacking means I must be careful where I click (if I accidentally click on the current workspace, it is not necessarily "safe") with my target area and thus speed being reduced. This was much worse before it was again limited to the current workspace by the patch in 124981, but it is still annoying. As a corollary, if I really did want another way to shuffle individual window stacking, I find the utility of the pager for doing so to be very poor since the target area to click on is often incredibly small. Oh, and btw: it's libwnck/libwnck/pager.c not window.c. ;-)
Heh, wrote that window.c part after the fact and didn't check my work. Yup, that's the exact reasoning for not having the pager do this. :-) Seeing as we're in a freeze we have to get approval from the release team or wait for the next release. I'll add the BLOCKED_BY_FREEZE keyword since it is true either way.
I'm putting this on the Gnome 2.8.x milestone so that it can get fixed...
Shows what I get for stating that a certain change would work without testing it... Anyway, deleting the lines as I stated above are the correct fix for libwnck, but they have a side-effect which needs to be fixed by a Metacity patch. When the user clicks on the pager, Metacity focuses the panel (since the pager is part of the panel). libwnck then sends a _NET_CURRENT_DESKTOP message corresponding to the workspace icon clicked on. If that happens to be the current desktop, then metacity finds that it already has the right workspace activated and thus does nothing; meaning that the panel still has focus. This makes perfect sense from a technical viewpoint, but a user probably expects the window that had focus to retain focus if they accidentally clicked on the current workspace. (Just as they expect the most recently used window to retain/regain focus when clicking on another workspace and then clicking again to return to the original workspace.) Unfortunately...although it's a simple patch to Metacity to get this behavior ("if the _NET_CURRENT_DESKTOP message specified a different desktop then activate it, otherwise activate the default (or previously focused) window for this workspace"), doing this would result in the race condition from bug 149589 returning when using the tasklist. So, bug 128380 will need to be fixed first. Fixing that bug may mean changing gtk+ documentation... Or, we could fix this side-effect bug by making Metacity not focus the panel when clicking on it, except when it really should be focused. But that sounds like an EWMH extension and lots of work... I'll work on fixing the side-effect stuff, but in the mean time, what's worse? The current behavior, or defocusing the currently active window when the user clicks in the pager for the current workspace?
Note to self: s/otherwise activate the default (or previously focused) window/otherwise activate the previously focused window/. The default window won't work, because if the user interacts with other panel applets before clicking on the pager, then using the default window would mean that the user gets surprised by some window on the desktop suddenly gaining focus when they clicked on the pager. Luckily, the patch in bug 128200 provides the framework for this, so this isn't a big deal.
I think defocusing the current window when you click on the current space is not such a big deal. I'd suggest applying this change. To get it right eventually: I'm not a huge fan of having _NET_CURRENT_DESKTOP change the focused window... I think we will need to confront some relatively complex solution for getting the panel to focus on click only when it should. I think there have been some discussions of this on wm-spec-list, maybe in the context of gok/magnifier. A workable solution might be that windows can set a "do not focus me on click" sort of hint, maybe DOCK does that by default, and then a GTK feature that manually focuses a "do not focus on click" window if certain widgets such as entry boxes are clicked. Anyway, maybe I shouldn't start this discussion here, the list would be better.
Ok, I committed the fix. However, one question: You say you're not a fan of having _NET_CURRENT_DESKTOP change the focused window, yet it already does that if it corresponds to a different workspace. Why is it a bad idea to have it change the focused window for the current workspace? (Assuming, of course, that focus changes to the window the user expects, which may just be the window that is already focused)
if _NET_CURRENT_DESKTOP switches you to another space, wouldn't it always focus the window that was previously focused on that space (in click to focus) and the window under the mouse (in mouse/sloppy)? In that case it isn't really changing the currently-focused window with respect to the workspace.
I thought you might ask that. ;-) Okay, let me describe my question a little more clearly. If _NET_CURRENT_DESKTOP switches you to another space, you are correct about the behavior that occurs. But I think the viewpoint from which you look at that behavior is important. From the end-user viewpoint, the window focus hasn't changed. From a technical viewpoint, meta_window_focus was called after the workspace switch and the focus window _did_ change (it just happened to change to what the user already thought would be focused). My question was really asking: "Is there anything wrong with having _NET_CURRENT_DESKTOP set the focus to what the user expects, since it does that when switching workspaces anyway?" Since the remaining issue we are talking about only affects Metacity and the libwnck part of everything is fixed, I'm reassigning this.
I think the smarter "relatively complex solution for getting the panel to focus on click only when it should" can be handled by the _NET_WM_TAKE_ACTIVITY EWMH extension--see bug 152952 (in particular, the 6th additional comment of that bug).
The extra issue is being discussed in bug 160470 and was mentioned on the wm-spec-list, so I'm going to retitle this bug back and reassign back to libwnck and resolve since these are separate bugs now.