GNOME Bugzilla – Bug 75613
Workspace pseudo-layout not behaving logically when edge-flipping
Last modified: 2009-08-16 15:13:28 UTC
Hello, Now that viewports have been eliminated: Workspace switching / edge-flipping needs to behave differently than its currently implemented, depending on which edge you're flipping by. If you have your workspaces organized in a 2x2 layout, for instance, the workspaces appear to be numbered as follows: 1 2 3 4 (This description assumes you are starting in workspace 1) Right now edge-flipping via the bottom edge currently does the same thing as edge-flipping via the right edge - they both go to the putative workspace 2. Instead, edge-flipping via the bottom edge should take you to workspace 3, while the right edge should continue to go to workspace 2. Thank you.
Viewports haven't been eliminated in sawfish (in gnome perhaps?) Sawfish puts no 2d interpretation onto the sequence of workspaces, so it's not possible to solve this properly within sawfish
Mark, any thoughts on this? You did the new pager stuff, right? or is that all libwnck?
Yeah, libwnck .... Havoc is who you want (as usual :-)
My view is more or less "edge flipping is bad UI and I don't care about it and it shouldn't be in the preferences," so I'm not sure you'll get much action out of me on this. ;-) But FWIW the basic solution is to define a geometry for workspaces, then have the pager and sawfish coordinate on this. This was discussed on wm-spec-list a bit but not resolved. Anyhow the bug is first in the WM spec, then in both Sawfish and libwnck to implement the spec.
FWIW, IMHO, edge flipping isn't great UI for the main workspace, but it makes a lot of sense on the pager. You've got a representation of little windows you can drag around; it is intuitively correct that if you can drag it around within one window in the pager you should be able to drag it from one part of the pager to another, assuming they are contigous.
Oh you can already do that, I didn't think that's what the bug report meant. Is it broken dragging little mini-windows inside the pager?
Actually, it doesn't here, but that's a separate bug. I was just defending the general 'edge flipping is bad ui' claim, which is probably mostly true but I don't think always the case.
Is there a bug about dragging the mini-windows? it works perfectly for me. You can't _move_ windows this way though, other than moving them between workspaces - that's deliberate.
I wasn't referring to dragging things around in the pager. I was referring to dragging an actual application window from workspace to workspace. While you may think edge-flipping is bad UI, I think if you poll end-users you'll find a large number of us use it. :-) <rant>It seems like a lot of UI decisions lately were made without much actual user input, but I digress... </rant> Anyway, since viewports are not being supported in Gnome 2.0, the artificial spatial relationship between the multiple workspaces (of which Havoc spoke) needs to have some logic and consistency. With four workspaces, this artificial relationship is presented as a 2x2 grid in Gnome 2.0. Dragging a window from one workspace to another (edge-flipping) needs to behave as if the workspaces were viewports (per Gnome 1.4). If you drag a window downward from workspace 1, you shouldn't end up in the same workspace as when you drag a window rightward from workspace 1.
I agree that edge flipping should work if the feature exists, I just would address the problem by nuking the feature. The vast majority of users do not want it or use it. Features most people don't use have high costs in UI complexity, implementation complexity, developer time, QA, bugs, support costs, and many other factors. Thus they should die, unless they are really _necessary_ for some subset of users, e.g. accessibility features. It's not that we don't listen to users, it's that we consider the big picture of all users, and understand that there are tradeoffs between adding a bunch of unimportant features and making the core features work well and be stable. But if someone gets a method for handling this in the window manager spec then I'll add support for it to the pager.
same here, I guess. If sawfish can at some point deduce the spatial relationship of workspaces used by the pager, we can look again at supporting that in the edge flipping..
*** Bug 77666 has been marked as a duplicate of this bug. ***
I hate to act like a jerk about this, and I know that I'm just a user and not a developer so I don't get a lot of say about the UI... But moving windows around between my workspaces (or viewports, I guess) worked just fine in gnome1.x, so why is it so hard to fix in gnome2? This is a feature that I show off to Windows and Macos users all the time, and it's something that they consistently mention as a reason to switch to GNOME and Linux from their OS. Let me see if I can get the reasoning straight here-- we got rid of viewports because it didn't make sense to have viewports AND workspaces. Then workspaces don't make sense spatially w/r/t edge-flipping, so we ditched edge flipping. Now it's hard to move windows around between workspaces. Are we going to ditch window movement between workspaces? And at that point, are we going to ditch workspaces completely? People suggest that users move windows between workspaces by dragging them in the pager, but that only works when you have a small number of them. If you have, say, twelve, the mini-windows don't appear in them any more, and even if they did, it'd be a matter of just a few pixels to manipulate.... Please reconsider having some sort of logical way to move windows between workspaces.
There's a thread about this on wm-spec-list now I restarted. I only care about it for the geometry-based keybindings though (arrow key around spaces). I still think edge flipping is inferior to: - "Send to Workspace N" window menu item - Alt+space to get window menu, N to send to that space - Pick up window with mouse, flip workspaces with keyboard, drop window - Move the window in the pager - Fixed "send to space N" bindings such as Alt+Ctrl+F3 to send to space 3, or something The edge flipping: - confuses people - breaks slamming window to the edge of the screen - only works for adjacent spaces So I'd still close this bug. But it's not my bug so I won't. ;-)
Obviously I'm biased since I opened this bug report. :-) But I thought it had been pretty well demonstrated that using keystrokes for actions was less efficient and more distracting than using the mouse, even if it "feels" like using keystrokes is quicker. Also, I don't see how edge-flipping can be confusing when it is turned off in the default setting. Anyway, I agree with Aaron 100%. The original argument for deciding to remove viewports was that workspaces can be made to function equivalently, if I remember Havoc's e-mails to gnome-list correctly. Since actually doing that is obviously not the intention of the Gnome maintainers, I think the original decision needs to be revisited. If it's one or the other, I'd get rid of multiple workspaces and keep the viewports, personally.
As you say the "original argument for deciding to remove viewports was that workspaces can be made to function equivalently" - key word _can_, there is no reason to have viewports just to get the features traditionally stuck to them. Whether you want each feature is an orthogonal question.
Right. So, what we're saying here is, we want that feature: logical, spatial, workspace-based edgeflipping. (Also overlapping.) And dammit, "People like it" is TOO a good reason to have a feature.
Let me put in 2 cents: I really enjoy edge flipping (with zero mouse resistance) in a 2x2 setup. I just flip around the four different screens very quickly (as opposed to a 1x4 setup). It is a real productivity increase. Having said this, I understand it is NOT going to happen for 2.0.0. Lets punt it down in priority, but lets not drop the idea altogether.
There's an attachment in bug 82337 that implements the "workspace-grid" <-> "workspaces" mapping in order to provide view-workspace-<right,up,left,down> commands. That code could be modified into something that would fix this bug.
I believe that edge flipping + 2d workspace geometry is a very efficient form of window management. Havoc, could you please support your argument that "edge flipping is bad UI" and "confuses people", as well as "[the] vast majority of users do not want it or use it [edge flipping]"? It seems you are making statements about the user base without any evidence. Besides, in my opinion a 20% user base would be sufficient to warrant support for a feature. It seems that the argument going on here effectively says that if the developers think that the majority of users don't use a feature, then it should be removed. I must agree with aaron@ximian.com and Travis Saling that this is an efficient feature. In fact, in my opinion, edge-flipping is much more intuitive than keybindings for a normal user -- nearly all normal users I know use the mouse for menus, etc., not keybindings. Keybindings are in fact much harder to understand, even if they are more efficient. With edge-flipping, what is easier to understand: that if you move a window past the right edge of the screen, it goes to the screen to the right, or that if you press the right combination of buttons, the window moves to some other screen, which is connected to the former screen by some numeric system (1 to 2, 2 to 3)? Anyway, it would be greatly appreciated if someone could actually have a poll on this subject or something.
C., if you want the big metaphysical essay you can find it here: http://pobox.com/~hp/free-software-ui.html Basically, the UI should make decisions. Not be the union of all possible UIs ever. Even though many of those UIs may be fine, having all of them at once is not fine - all good UIs combined make one bad UI. Moreover, spending time on writing/debugging/maintaining dozens of flavors of functionally-equivalent UI is silly when there are other more interesting things to do, IMO. And no patches don't help much here - no one ever _maintains_ the patch after they submit it. ;-) Edge flipping is not the best decision for the default, because it breaks fitt's law (ability to slam your mouse to the edge of the screen), it causes a big/jump/surprising context switch without an explicit user action like clicking a button, and it's a complicated pain to implement. This is edge flipping just to change workspaces. Edge flipping _while moving a window_ is perhaps a bit more defensible UI-wise, and easier to implement, but still has some of the same concerns. But in any case, this is a Sawfish bug report, and Sawfish already has edge flipping AFAIK. So no real issue here.
All that's needed to fix this is to change lines 126-137 in wm/ext/edge-flip.jl from: (cond ((eq edge 'left) (previous-workspace 1) (rplaca ptr (- (screen-width) 2))) ((eq edge 'right) (next-workspace 1) (rplaca ptr 1)) ((eq edge 'top) (previous-workspace 1) (rplacd ptr (- (screen-height) 2))) ((eq edge 'bottom) (next-workspace 1) (rplacd ptr 1))) to: (cond ((eq edge 'left) (view-workspace-left) (rplaca ptr (- (screen-width) 2))) ((eq edge 'right) (view-workspace-right) (rplaca ptr 1)) ((eq edge 'top) (view-workspace-up) (rplacd ptr (- (screen-height) 2))) ((eq edge 'bottom) (view-workspace-down) (rplacd ptr 1))) ... including the view-workspace-* functions from the workspace-grid.jl attachment in bug 82337.
I happen to agree with Havoc that edge-flipping is bad UI because it's confusing for users to have their windows disappear on them because they held their mouse cursor too close to the edge of the screen for a few milliseconds too long, HOWEVER, I think the feature should be able to be enabled as a pref or hidden pref because it is something that a lot of people want. I just don't think it should be enabled by default. For some people edge-flipping really does enable them to work faster and more efficiently. I don't think the solution to users requesting a feature is to say, "No, you really don't want that feature." And no, I don't think that every feature that is requested should be implemented, but this is one case where a large number of users want this feature and have used it in GNOME 1.x. I personally won't use this feature, but I thought I'd give my 2 cents. -jamin
Hmm, I just voted "yes" on the poll, but now that I'm reading the comments here, I think I voted yes to something else than I thought. Edge-flipping (switching workspaces when mouse hits the edges) is a bad idea, but what exactly is wrong with being able to *drag* windows from workspace to workspace? Ie., edge-flipping, but only when you are dragging a window. Fitt's law doesn't apply here, because there is nothing to do at the edge of the screen when you are dragging a window.
The poll referred to is: http://pubcrawler.org/modules.php?name=News&file=article&sid=36&mode=nested&order=1&thold=-1
Edge flipping while dragging a window, with some edge resistance perhaps, is arguably more defensible yes. I'm still not sure it's OK to turn on by default.
What about a compromise... With Metacity you can snap the window to edges when holding down the shift key. So why not do edge flipping when holding down another key like ALT? When pressing this key and grabbing the window, all the screensides that have a workspace behind them could turn red (or whatever is possible in X to make it look nice) to indicate you that you can move your window above this "border" now. This would also have to temporarily disable Metacity's habbit to block the window at the top panel so it can actually be moved above there. Of course this would require some safety check when dropping the window so it isn't covered behind a panel... There are a lot of things that could go wrong so it's probably questionable weither it's all worth it. However... Advantages would be: - It's even more impressive because of the visual stuff. - It never happens accidently to new users who don't have a clue what it is. - It also never happens accidently to experienced users who just forgot about this feature for a second (happened to me constantly when I just wanted to pull a window to a side, for example to read something on a window below it). Disadvantages would be: - New users probably won't discover this without *reading the fine manual*. - It's a little bit less convenient because you need to press an extra key while moving the window.
Can the UI decision be discussed elsewhere? This bug is that the sawfish implementation of edge-flipping doesn't coordinate with workspace pseudo-layouts. This has nothing to do with whether the feature should be enabled by default or not from a usability perspective. If you want to discuss the usability aspects, wouldn't it would be better to open a new bug, and add the "usability" keyword?
Created attachment 10143 [details] [review] A patch. Requires workspace-grid.jl from bug 82337.
Created attachment 10144 [details] [review] Woops, that last one was the wrong version. This is the right patch.
Because of changes to workspace-grid.jl, all calls to "view-workspace-<direction>" commands should be renamed to "workspace-<direction>" in the attached patch.
Cof Cof HP said: : I still think edge flipping is inferior to: : - "Send to Workspace N" window menu item : - Alt+space to get window menu, N to send to that space Both are less intuitive than dragging a window (specially if it's to the next space). : - Pick up window with mouse, flip workspaces with keyboard, : drop window Wow, two hands coordination! I'm sure the HIG likes this option. : - Move the window in the pager Smaller area to manouver in comparison to dragging the window between adjacent workareas. : - Fixed "send to space N" bindings such as Alt+Ctrl+F3 to : send to space 3, or something : The edge flipping: : - confuses people it ONLY confuses people who DO NOT KNOW of the feature and it is only unexpected to those who are not taught of it AND came from 1 workspace only desktops (like Windows and MacOS). When I first encountered this feature I had come from the world of MacOS. The very first time I accidently used it, I got confused. I moved the mouse more carefully to see how it worked and fell in love almost immediately as I understood the behaviour. My girlfriend comes from Windows... I taught her, and she likes it much more than using the pager (when moving from and to adjacent workspaces -- for larger distances she takes advantage of the pager). : - breaks slamming window to the edge of the screen Well, then you are probably using a bad window manager since edge-flip only happens when the mouse reaches the edge, not the window. So you just alt+mouse1-drag untill the window glues to the edge. : - only works for adjacent spaces Yes, that's the whole idea. I would certainly find it confusing if edge-flipping brought me not to the adjacent space but to the next one. Actually, edge-flip's importance is specially due (but not limited) to moving between adjacent spaces. Daniel Borgmann said: : So why not do edge flipping when holding down another key : like ALT? : Advantages would be: : - It never happens accidently to new users who don't have a clue : what it is. It doesn't happen accidently to new users who don't have a clue if it's off by default, and activated, say, with gconf. : - It also never happens accidently to experienced users who just : forgot about this feature for a second (happened to me constantly : when I just wanted to pull a window to a side, for example to read : something on a window below it). Even though this happens very rarely, a better way to do what you want is: C-right-click1 makes window raise/unraise on my sawfish configuration. : Disadvantages would be: : - New users probably won't discover this without *reading the fine manual*. That's already happening in relation to some of the cool gnome features, only the difference is that these features are not really in the fine manual (unless you include the source code into the definition of manual). However, I still consider gtk2/gnome2 a huge forward step.
Alright, since people are STILL discussing the usability issue on this bug report, I went ahead and opened a new bug myself. Please go to bug 90659 if you want to keep arguing about this.
Committed the patch now, with the necessary name changes..