GNOME Bugzilla – Bug 81704
Edge magnetism/resistance/snapping/etc.
Last modified: 2007-05-22 20:49:29 UTC
Add some kind of mild "attraction" to window/screen edges, perhaps only after a timeout. Need to experiment.
agree, I would very much like to see this in Metacity!!
Marking this enhancement just to keep track of things, Havoc, but you might want to go through and mark some enhancements as higher or lower than others according to your own taste.
*** Bug 82746 has been marked as a duplicate of this bug. ***
Don't know if I should file another bug for this, but in the gnome2 release of metacity the edge magnetism almost works. It attracts to panels at least. There is a problem though, if you resize a window to be just barely taller than the space between the two panels. Set the bottom of the window on the bottom panel. Then resize the window from the bottom going toward the top. Insted of it moving the bottom off the panel, it moves the top down, and leaves the bottom magnetized to the panel. You have to try it to see what I mean, it is kind of trippy.
There isn't any edge magnetism as far as I know... the weird resize bug I know about, it's kind of annoying to fix. been thinking about it.
*** Bug 87790 has been marked as a duplicate of this bug. ***
*** Bug 92627 has been marked as a duplicate of this bug. ***
Created attachment 12034 [details] [review] Improved edge snapping patch
Created attachment 12058 [details] [review] Edge magnetism patch
Adding patch keyword.
*** Bug 97792 has been marked as a duplicate of this bug. ***
Oh, I hadn't noticed we had patches here. I'll look at them (probably after GNOME 2.2 is out)
*** Bug 102487 has been marked as a duplicate of this bug. ***
Adding myself to the CC, edge magnetism would be a major usability plus :)
We need some discussion on the exact desired behavior (we may need to put in a patch and experiment a bit). Some variables: - we can do edge magnetism (as you approach within THRESHOLD of an edge, the window jumps to it), or edge resistance (when a window reaches an edge, you must move THRESHOLD past the edge before the window moves past the edge) - we can make it a hard constraint (if within THRESHOLD of the edge, window is always snapped to the edge) or only snap after some timeout, or relax the constraint after some timeout. - we can make it independent of direction of mouse motion, or for example only have edge resistance/magnetism if you are moving "toward" the edge in question The timeouts or direction-sensitivity would be ways to try and make windows snap to edge by default but allow you to override the snap if desired. My feeling is that the direction-sensitivity would feel a bit unpredictable and the timeout would be a better approach there. For the timeout, relaxing the constraint after the timeout makes a lot more sense to me than kicking in the snapping after a timeout, since snapping is usually what you want. Resistance vs. magnetism: resistance does not do any good for the edges of the screen, is one argument against it. Also with magnetism you don't have to move the mouse as far. Both these patches are for magnetism. So my off-the-cuff view is: - magnetism - fairly small THRESHOLD, maybe 5-10 pixels - after a timeout, the magnetism is disabled until the mouse moves outside and back inside THRESHOLD Clearly we'll need to try it out, and experiment with values for the timeout and threshold. Other opinions?
I think THRESHOLD should be exceedingly small, like say 3 pixels. That gives you a +/-6 pixel gap where the magnetism/resistance applies. 10 pixels is way too much. (+/- 20 pixel gap). I think key here is that when moving a window quickly across the screen, it shouldn't "jitter" as it goes snapping to everything in between. A very short timeout interval before snapping ought to handle that case. Another problem I see here is that some people aren't going to like the magnetism/resistance/whatever, so we need to try to make it useful, but low-key and more subtle. (hence the small threshold)
I don't know if this has been considered, but it may be nice if windows attracted to each other as well, so you could easily line up windows. I can see this being useful for apps like gaim where you may want the main window and conversation window connected. Also (if its possible) a modifier+drag could drag the attached windows together (although I imagine this might be really hard considering the already limited number of keyboard modifiers).
*** Bug 106980 has been marked as a duplicate of this bug. ***
An additional point: the current find_nearest_[horizontal|vertical]_edge functions are on crack for this purpose. For snapping, left edges of windows should only attract to right edges of windows. Similarly right edges to left edges, top to bottom and bottom to top. I've played around a bit with the first patch, and I think that actually 6 pixels is about right. Small enough to be unobtrusive but large enough to be useful. 6 pixels also means that when keyboard moving, you can both snap to edges as you go, and also not get trapped by edges. Also, I find that it is small enough that there's no noticable jitter effect if you move windows quickly across the screen without any sort of timeout value. The first patch also reverses the sense of the shift modifier to mean "DON'T edge snap", rather than "get funky with the edge snapping" like current metacity, which strikes me as highly sensible, though we might want to do something about the shift+keyboard move thing. Does anyone use that? It always struck me as a bit on crack. The second patch appears only to snap to work area edges; I don't see that as quite as useful. Plus, it won't work any more without modification :-).
In general I think it's probably wrong to try and define such things in terms of n pixels... while 6 pixels works well for you, it will probably vary for different display resolutions and sizes, and from user to user. Rather than introduce a new preference, though, perhaps one option would be to define the distance as some function of the drag and drop threshold that the user can define in the Mouse Preferences dialog? Or maybe just a function of the user's chosen mouse speed or sensitivity. One of those things, anyway :) (The same should probably go for the distance you have to pull maximized windows away from the top of the screen before they "shake loose", to better accommodate users with slight hand tremors etc.)
I would avoid magnetism in favour of edge resistance. Magnetism has a whole host of things that can make it very annoying. Also, the idea of things providing temporary resistance is *much* more normal in the real world than things attracting eachother (which basically only happens with magnets...).
Well, it also happens with "everything" and "everything else", if that Newton dude is to be believed :)
Seth, just for the sake of intelligent discussion here, could you describe a sample of the things that make edge magnetism very annoying? Ideally we'd implement the Correct (TM) behavior here and leave it at that. -Rob
Patch has fallen out of sync with comments, so unmarking PATCH keyword/High priority.
Any chance of this feature making it into GNOME 2.4?
No, feature freeze for 2.4 was yesterday. Feature freeze comes undone for GNOME 2.6 in 3 months or so. No reason to delay writing a patch though, GNOME 2.6 is next spring, so is not very far away really.
An argument for resistance over magnetism: Resistance "feels" right. Specifically, you move toward, say, the edge of the screen, the window moves as expected until it hits the edge of the screen, at which point it "bumps" into it and stops unless you keep moving, pushing past the block. The edge of the screen is a border, and borders (any borders) are a place where you are blocked or at least slowed down. My control over window placement has been restricted (I need to "push harder" to get the window over the edge), but never taken away from me. Conversely with magnetism, you move near the edge of the screen, then your window jumps away from your cursor. There is nothing fundamentally "attractive" about edges (or other windows, or whatever else you want to snap to), so it's surprising behavior. Control has actually been taken away from me, my window moved somewhere I didn't place it. The possibility of using a timeout to disable the behavior seems odd to me. If my window doesn't go where I want, waiting isn't a natural reaction. My reaction is to move the window further in the direction that I want. So, I suggest disabling the edge resistance when the window moves "far enough" out of the resistance zone. The only downside I see is that this means that you can place windows just barely off the edge of the screen (say, putting your GIMP toolbar just off the edge of the window so that the left buttons are exactly on the edge of the screen, giving those buttons an effectively "infinite" width).
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Created attachment 25228 [details] [review] Resistance/magnetism patch for 2.6.5
I've attached a patch against metacity-2.6.5. The patch adds edge resistance (which I think is the better mode) and magnetism. The behavior is still different from other WMs, it snaps to almost anything -- but I actually start to like this behavior somehow.
Thanks for the patch. We will be able to consider it after the release of Gnome 2.6, since we are currently in feature, string, and hard code freeze.
Patch shouldn't have a preference to start with, it should just pick a good default and hardcode.
*** Bug 143155 has been marked as a duplicate of this bug. ***
XMMS has this behavior. It'd also be nice if you added attraction not only to screen edge, but to other windows and to the gnome panel.
My 2cents in favour of resistance: I currently use fvwm, and used twm/tvtwm before that. All of these have some kind of edge resistance. One of the reasons why I'm not comfortable with metacity is the absence of edge resistance.
Created attachment 32806 [details] [review] the resistance patch reworked for CVS HEAD I reworked this patch so it will apply to CVS HEAD because I wanted to try it out. I've left in the preferences for now, however I'm planning on removing it pretty soon. The resistance mode works fairly well however i think it needs a little bit greater resistance value.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Cool patch. There's two possible issues I see with it (I'm discussing from the viewpoint of assuming we'll go with resistance; I think snapping/magnetism doesn't make sense as I'll discuss below): (1) If I move a window towards another so that they align but don't overlap, and then try to pull that window back away, it acts as if it were stuck to the other window. I guess you could call this "sticky resistance", but it's not what I would expect. (2) Resistance also occurs when the left sides of two windows align (i.e. not just when the two windows initially meet, but also when the tail side of one window meets the front side of the other). Same goes for the right side. Again, this isn't quite what I expected. I guess a good way to summarize the above two points is that I was assuming that we would want only left/right matchups to generate resistance and only when the windows were moving towards each other. (The idea being that the windows are at the same depth when they're separate, and it requires extra effort or force to push one out of the way so that one can cross over the other) There may also be an enhancement possible: It is probably much more common to want to align windows with the screen edge than to want to move windows off the screen. (This is an assumption I don't have proof for, but I'd be surprised to hear otherwise at this point). Currently the user can't throw their mouse towards the side of the screen if they want their window to align with it--they'll probably overshoot by more than the resistance threshold. We'd have to raise the current threshold to a really high level to even partially accomodate this kind of action, but that'd destroy things for window-window resistance. However, we might instead be able to make things easy to line up with the screen by adding a timeout when the window hits the edge of the screen and the window isn't allowed to move past the edge unless the user is still moving the window when the timeout lapses. Thoughts? Opinions? An attempt to continue Seth's and Calum's usability argument about resistance vs. magnetism: Let me start by responding to comment 22: Only huge objects like planets are sufficiently large to create noticeable gravitational force. Saying gravity would be the real world analog of window attraction in the window manager says that either (a) one of the windows dwarfs the other in size by several orders of magnitude (i.e. matches people's experience with manipulating objects relative to the earth--this would mean that we only get attraction in the window manager when one of the windows is nearly fullscreen and the window being moved is about a single pixel or so in size), or (b) that the end user has experience moving planets around while they're in relatively close proximity to each other. Like Seth, the only other analogy besides gravity that I can think of for window attraction is magnets. But most objects are not magnetic and I see no reason a user would expect a window to be magnetic. Unless, perhaps the user has a metal theme--maybe we can detect what the theme looks like and turn on edge snapping in those cases? ;-)
After spending some time experimenting with this patch, I was liking it set to 'resistance', with no changes to the patch itself. After much, much more time with it, I found that it's best for me when DRAG_THRESHOLD_TO_SNAP_THRESHOLD_FACTOR == 0.3 while using 'snap' setting. When I'm just moving windows around casually, I'm normally moving the mouse at a relatively fast pace. When I know exactly where I want my windows, I tend to use slower, more deliberate movements. With DRAG_THRESHOLD_TO_SNAP_THRESHOLD_FACTOR at 0.3 and move_assistance at 'snap,' the effect is both subtle enough to not bother me when I'm casually tossing windows around, and helpful enough to let me be just a little less careful while moving windows to line up together. Maybe the reason for this is that with just plain resistance, I have to slow down before I hit the edge I'm looking for to avoid going past it. A crippled snap lets me move at a more constant speed and then just stop. It feels faster. Just my two cents.
First of all an excellent patch! There seams to be a bug. If you place a couple of small windows behind a large window, the patch sees the windows bebind, and snap/resist to those aswell.
I shouldn't have put this on the 2.10 Gnome Milestone, since it's an enhancement, and not a showstopper.
*** Bug 165454 has been marked as a duplicate of this bug. ***
Would it also be possible to have resistance on screen edges of xinerama setups even when not dragging windows? Corner menus and icons work very well in single screen setups, but I find myself throwing the mouse off the edge of one screen and onto the other when the applet is on the border of the two monitors (panels don't span the two screens). It would be nice to have the mouse stick a little to the current monitor before venturing over into the next one.
Would it be possible to edge resistance *soon*? This one of the most requested metacity enhancements and it has been put off numerous times. Whoever adds it, I'll gladly buy you $BEVERAGE or even $LUNCH the next time you're in Boston. Thanks!
I've been planning to take a look at this for 2.12.x
http://www.google.com/search?hl=en&lr=&c2coff=1&q=Stallman+%22sooner+if+you+help%22&btnG=Search
Created attachment 48029 [details] [review] re-working for CVS HEAD w/o tesing it. I haven't tested this new one, but was asked to make this build again. So here's the latest rework... Good Luck!
I can confirm that it works perfectly with Fedora Core 4 and Metacity CVS. In Nautilus have the desktop icons the snap feature. Perhaps this value would be good for snap-to-borders aswell?
what about resistance of the bottom of windows to _NET_WM_WORKAREA as well? Would it make sense to implement this using WORKAREA as a constraint in addition to/rather than screen area? Apologies if the patch already behaves this way - it's not apparent from reading it. Using WORKAREA would be nicer for a11y and arguably for other users as well.
I think it would be nice if this magnetism/resistance would show up when resizing a window and not just when moving one.
Magnetism/resistance when sounds to me like a very good idea, but I can't figure out, if it would require the curser to be moved with the window as the resize corner only is a few pixels wide.
Resistance is a much less intrusive method that doesn't cause confusing and annoyance, but it seems to be very individual. Snapping is more fast for power users, but I was forced to use resistance for a day or two, and suddenly it became a much nicer way of moving around. I crave the basic windowing features of openbox in metacity. I suggest a way to choose between the two techniques as the recent reworked patch has implemented. I suggest adding this feature chooser using radio buttons in the Desktop -> Preferences -> Windows dialog with a checkbox to enable the effect and two radio buttons to choose behaviour. ASCII Mock-up for the addition: _Window movement_ [x] Enable window edge effects (·) Resistant movement ( ) Magnetic movement I would love to help development, but compiling any part of gnome just scares the heck out of me. Last time I tried I spent an entire day trying to compile Luminosity... maybe that was a long-shot anyway...
I really like the patch. There are two minor bugs: The window you are moving can become snapped to an occluded window and in reduced resources mode the window can snap to itself. Also, the patch doesn't apply cleanly anymore and patching fails on window.c.
I have just read my own post #51, and it doesn't really make sence. What I was trying to say is: I think magnetism/resistance during resize would be very useful, but the mouse arrow might need to be moved together with the window when snapping/resistance occurs...?
[Cue Wizard of Oz music] Ding! Dong! The bug is dead! The wicked bug, The wicked bug, Ding! Dong! The wicked bug is dead...
ed eh3 com now owes me a $BEVERAGE or $LUNCH if I ever make it to Boston again... ;-)
Hi Elijah, thats cool! And yes, please contact me anytime to collect!
I have just tried 2.13.2, where 3 types of resistance are included, but not snap-to-border. What have been the main advantages and disadvantages of snap-to-border and resistance? http://ftp.acc.umu.se/pub/gnome/sources/metacity/2.13/metacity-2.13.2.news
auto-snap-to-border exists just as before -- just hold shift while moving.
That's of course true. The way I see it, snap-to-border and resistances solves two different problems. Snap-to-border makes alignment of windows very fast, where resistance gives the user protection from moving windows without purphase. I don't think resistance can replace snap-to-border or visa versa.
The amount of utility that that magnetic windows present, unless configurable, vary among resolutions, and is much better for window grouping strategies than edge resistance. The amount of utility that edge resistance presents, unless configurable, also vary among screen resolutions. I would prefer having magnetic windows over edge resistance, but some might like the other way around, so I think both would be good.