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 75613 - Workspace pseudo-layout not behaving logically when edge-flipping
Workspace pseudo-layout not behaving logically when edge-flipping
Status: RESOLVED FIXED
Product: Sawfish
Classification: Deprecated
Component: Window Manager
pre-1.3.x
Other other
: Normal major
: 1.5.x
Assigned To: John Harper
sawfish QA Team
: 77666 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-03-20 16:25 UTC by Travis Saling
Modified: 2009-08-16 15:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A patch. Requires workspace-grid.jl from bug 82337. (1.08 KB, patch)
2002-07-31 08:34 UTC, Michael Toomim
none Details | Review
Woops, that last one was the wrong version. This is the right patch. (1002 bytes, patch)
2002-07-31 08:44 UTC, Michael Toomim
none Details | Review

Description Travis Saling 2002-03-20 16:25:19 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.
Comment 1 John Harper 2002-03-20 18:18:08 UTC
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
Comment 2 Luis Villa 2002-03-20 22:14:03 UTC
Mark, any thoughts on this? You did the new pager stuff, right? or is
that all libwnck?
Comment 3 Mark McLoughlin 2002-03-21 11:06:14 UTC
Yeah, libwnck .... Havoc is who you want (as usual :-)
Comment 4 Havoc Pennington 2002-03-21 15:23:56 UTC
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.
Comment 5 Luis Villa 2002-03-21 23:21:42 UTC
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.
Comment 6 Havoc Pennington 2002-03-21 23:56:16 UTC
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?
Comment 7 Luis Villa 2002-03-22 00:01:03 UTC
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.
Comment 8 Havoc Pennington 2002-03-22 01:02:09 UTC
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.
Comment 9 Travis Saling 2002-03-22 01:07:28 UTC
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.
Comment 10 Havoc Pennington 2002-03-22 02:37:36 UTC
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.
Comment 11 John Harper 2002-04-03 06:44:22 UTC
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..
Comment 12 John Harper 2002-04-18 17:06:45 UTC
*** Bug 77666 has been marked as a duplicate of this bug. ***
Comment 13 aaron 2002-04-24 16:56:44 UTC
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.
Comment 14 Havoc Pennington 2002-04-24 18:36:26 UTC
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. ;-)
Comment 15 Travis Saling 2002-04-24 19:53:24 UTC
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.

Comment 16 Havoc Pennington 2002-04-24 21:42:58 UTC
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.
Comment 17 aaron 2002-05-24 21:53:09 UTC
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.
Comment 18 Wayne Schuller 2002-06-03 01:45:21 UTC
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.
Comment 19 Michael Toomim 2002-07-02 04:43:23 UTC
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.
Comment 20 Constantine Evans 2002-07-08 02:06:10 UTC
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. 
Comment 21 Havoc Pennington 2002-07-08 02:56:12 UTC
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.
Comment 22 Michael Toomim 2002-07-13 10:34:37 UTC
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.
Comment 23 jgray 2002-07-30 20:40:57 UTC
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
Comment 24 Soren Sandmann Pedersen 2002-07-30 21:50:07 UTC
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.
Comment 26 Havoc Pennington 2002-07-30 23:08:08 UTC
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.
Comment 27 Daniel Borgmann 2002-07-30 23:20:09 UTC
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.
Comment 28 Michael Toomim 2002-07-30 23:27:13 UTC
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?
Comment 29 Michael Toomim 2002-07-31 08:34:02 UTC
Created attachment 10143 [details] [review]
A patch.  Requires workspace-grid.jl from bug 82337.
Comment 30 Michael Toomim 2002-07-31 08:44:27 UTC
Created attachment 10144 [details] [review]
Woops, that last one was the wrong version.  This is the right patch.
Comment 31 Michael Toomim 2002-08-13 05:07:52 UTC
Because of changes to workspace-grid.jl, all calls to
"view-workspace-<direction>" commands should be renamed to
"workspace-<direction>" in the attached patch.
Comment 32 Rui Miguel Seabra 2002-08-13 14:15:32 UTC
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.
Comment 33 Michael Toomim 2002-08-13 17:33:02 UTC
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.
Comment 34 John Harper 2002-08-18 21:29:16 UTC
Committed the patch now, with the necessary name changes..