After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 100470 - Clicking on a window in the workspace list shouldn't raise it
Clicking on a window in the workspace list shouldn't raise it
Status: RESOLVED FIXED
Product: libwnck
Classification: Core
Component: general
2.7.x
Other other
: Normal normal
: ---
Assigned To: libwnck maintainers
libwnck maintainers
Depends on:
Blocks: 155450
 
 
Reported: 2002-12-05 22:03 UTC by Dave Camp
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: 2.8.x
GNOME version: 2.7/2.8



Description Dave Camp 2002-12-05 22:03:00 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.
Comment 1 Calum Benson 2002-12-13 18:33:21 UTC
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 :)
Comment 2 Havoc Pennington 2002-12-13 19:36:33 UTC
I generally agree, not sure this was deliberate.
Comment 3 Kees 2004-02-25 21:25:05 UTC
*** Bug 126482 has been marked as a duplicate of this bug. ***
Comment 4 Kees 2004-02-25 21:34:20 UTC
This (annoying) behaviour is still present in libwnck 2.4.0 (FC1)
Comment 5 Bryan W Clark 2004-08-31 20:44:03 UTC
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
Comment 6 Elijah Newren 2004-08-31 21:20:41 UTC
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.  ;-)
Comment 7 Bryan W Clark 2004-08-31 22:04:29 UTC
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.
Comment 8 Elijah Newren 2004-09-12 23:53:11 UTC
I'm putting this on the Gnome 2.8.x milestone so that it can get fixed...
Comment 9 Elijah Newren 2004-09-14 05:24:41 UTC
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?
Comment 10 Elijah Newren 2004-09-14 05:34:20 UTC
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.
Comment 11 Havoc Pennington 2004-09-15 01:34:26 UTC
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.
Comment 12 Elijah Newren 2004-09-15 17:07:33 UTC
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)
Comment 13 Havoc Pennington 2004-09-16 19:07:36 UTC
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.
Comment 14 Elijah Newren 2004-09-16 19:31:53 UTC
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.
Comment 15 Elijah Newren 2004-10-01 18:42:33 UTC
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).
Comment 16 Elijah Newren 2004-12-20 17:14:14 UTC
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.