GNOME Bugzilla – Bug 105492
'Move to Workspace n' should only move, not flip
Last modified: 2004-12-22 21:47:04 UTC
Comment from a Sun customer, which I happen to agree with :) "if I select "Move to Workspace 4" then not only does it move the window, it also flips the desktop to workspace 4 to follow the widnow. This isn't what I want. If I wish to change workspace, I will do so, if I ask it to move a window then it should just do that and not do anything else. (Usually I'm moving a window that I don't want in the current workspace.)"
it used to work the way you say, and I prefer that myself as I usually find the workspace flip surprising. It would be nice to have some more solid basis for deciding the issue, though.
I think common sense and consistency are a solid enough basis here... Actions in the window menu are supposed to operate on the window, not on the workspace.
I tend to agree with the comments in this bug. I never use this feature, but when I tried playing with the menu it was strange to have the window still there. What were the original reasons to change it to the current behavior? -Rob
One solid basis I can think of is trying to keep things as ortogonal as posible. There are keybindings to switch-to-the-nth-workspace, and no one, I guess, doubts they are reasonable. Having one that moves-this-window-to-the-nth-workspace-and-then-switch-to-it then introduces a function-clash. In my own experience, 95% I want to move a window to another workspace, what I mean to do is move it but stay put where I currently am. The reasons which justified the current situation would certainly make interesting reading. ;)
I use the keybindings to move a window right/left/up/down regularly, and in this case I do expect that the workspace will move with the window. The keybindings wouldn't be all that useful if the workspace didn't move, since otherwise moving a window more than one workspace with these bindings would be a painful process. So at the very least these keybindings should work the way they currently do. The question that remains is whether the "Move to workspace n" is better with the switch or without, or whether it should be consistent with the left/right/up/down, or whether the keybindings should perhaps work differently from the window menu, or maybe something completely different.
This was changed in HEAD so that the window will just move, and the workspace will not switch. This makes the keybindings essentially useless; I think that we should either do the move and switch for both or have the menu just move and the keybinding both move and switch. I normally move windows around workspaces using the move left/right/up/down keybindings. What I _ought_ to be able to do is move the same window through any number of workspaces by repeatedly applying the keybinding. As it stands though, I have to move the window, move the workspace, re-aquire focus on the window with alt-tab, then move the workspace again. (note that it wasn't working perfectly before either; there's another bug in here about that) One thing I'm kind of wondering is why we need the menu to workspace switch at all. The pager already provides this functionality much better than the menu does. The only reason I can think of for having the menu is accessibility. In this case it seems like it would be better for the accessibility user if the window they were previously working with remains the focused window.
Hmm, I didn't think about the directional movement maybe being different from the "move to N" movement. Maybe we should distinguish those. Seems kind of inconsistent, though.
Try using the left/right/up/down keybindings to move windows; it's an excercise in frustration. Then try it with the attached patch.
Created attachment 16313 [details] [review] switch workspaces on left/right/up/down
Adding keyword.
"int flip" should be "gboolean flip" Otherwise I think this is OK to commit, though I have a nagging feeling that having "move to workspace 1" and "move to left workspace" do something different is kind of strange. Perhaps we should have both "move to space" and "bring to space" bindings possible or something. I don't know. Anyway, let's just check this in and close the bug and sort it out someday.
yea I have the same nagging feeling you do on that. Maybe we should change them all back to the way they were before. We'll see if anyone bitches about this though first :-) Committed. -Rob
Well, this isn't a bitch as such, but I do think having two different behaviours now is a *little* confusing, particularly when we can't have different backgrounds for each workspace-- there's very little visual cue as to what's going on in each case. Especially as they're both just described as "Move window..." in the keyboard shortcuts dialog. Perhaps if the left/right ones were called "Move and follow window one workspace left/right", or "Pull window to next workspace left/right" or something...? I dunno, can't really think of the right words at the moment, cc'ing the docs guys :)
That's especially true with maximized or fullscreen windows. With fullscreen there's really no way to tell at all. Maybe we should pop up the workspace dialog briefly when we do the switch?
Feedback makes sense to me, as does changing the description of the keybindings. (Opening a new bug is probably a good idea if we don't want to forget)