Created attachment 54958 [details] [review]
Allow differentiation between movement towards an edge and movement away from one

I haven't tried the current settings or even looked at what they are but I would
think the edge resistance should be fairly subtle (i.e. if you aren't looking
for it you almost might not notice, just enough to help align things)

Yeah, I think that makes sense and that the current settings don't do that (even
after this patch).  It was probably more of an effect of
bigger-makes-debugging-and-testing-easier but a few people have reported the
settings as being somewhat jarring (though with previous versions).  I'm
guessing the pixel distance values could probably be cut in half, but I'd really
like others to test and comment, especially the usability gurus...

Just had my first quick play with it.  I'd certainly agree that it feels a bit
too sticky at the moment, especially for the screen edges... even if we do want
them to be a special case, which personally I'm not yet super-convinced about--
I've never felt the need to 'slam' my windows into the corner before, and I
still don't now that it's possible :)  I like that you don't really notice the
effect when you're moving windows around quickly, though... except, again, at
the screen edges.

For a11y reasons, the stickiness perhaps ought to be some factor of the
user-definable drag threshold, so that users who are less agile with the mouse
can still take advantage of it... not sure about that though as it might equally
lead to snapping that the user didn't want; cc'ing Bill for comments.  I guess
the top-edge threshold should never be less than the titlebar height in the
current theme, either, so that even if you're using LargePrint, you still can't
drag a window off the top of the screen by dragging the titlebar alone. 
Otherwise somebody who didn't know about Alt+drag could do that by mistake, and
get themselves in a pickle.

I'm not sure about the implementation when moving with the keyboard... i.e.
having to press the arrow key twice (four times for screen edges) to 'get over
the hump' when you move near a window edge.  Maybe it would be better if, when
the next arrow key 'step' would take you nearly to an aligned edge, it just took
you exactly there, and the next press took you past it.  That is, pressing an
arrow key would /always/ move a window by some amount, just not necessarily a
consistent amount when you were near a window edge.

One feature I did find lacking was the ability to line up a window with two
edges of an adjacent window.  If window A is above window B, I can easily align
the bottom of window A with the top of window B.  But once I've done that,
there's apparently no resistance to help me line up (say) their left edges as
well, i.e. to get to this configuration:

 +---+
 | A |
 +---+---+
 |   B   |
 +-------+

Hmm, I guess it's not quite as simple as the threshold never being less than the
titlebar height (in my previous comment), as the height of the top panel comes
into play as well... but anyway, I'm sure you can figure it out if you haven't
already :)

You may not feel the need to slam windows to the corner right now, but I suspect
that's just as much training as anything else.  It felt really odd when I first
removed the titlebar-onscreen-constraint and didn't have edge resistance because
I found myself subconciously moving the window way too quickly towards the top
of the screen and had been relying on it to allow me to do things so quickly. 
Maybe I should give you a patch that removes all edge resistance at the top edge
of the screen and see if you still claim the same.  :)  In any event, this is
the one aspect that I'd like people to use for a while before we tweak it. 

I didn't explicitly mention it, but yes, there is an infinite resistance to top
edges if the move/resize was started from the titlebar (instead of via alt+drag
or alt+f7/alt+f8).

Useful notes on the keyboard moving/resizing.  Your request is actually what
those things use to do; I just had a more general framework and could allow
fancier stuff and decided to try some of it out.  It sounds like fancy may not
be better in this case.  :)

Your last feature was related to two other questions that I neglected to mention
in this bug:
  - Currently, the code ignores hidden edges and edges that are not in the
    path of the moving window, as would seem to make sense.  A side effect,
    though, is that windows which are adjacent don't feel any resistance when
    it might be nice to do that if there's an off-by-one distance between them
    (because of the exact example you mention).  Should I implement that?  It
    wouldn't be that hard at all.
  - Currently, edge resistance is only applied for opposing edges (e.g. left
    side of window coming up against the right side of another).  Should it be
    enabled for e.g. left-left matches as well (only when off-by-one or
    always)?
Implementing both of these would take care of your special case, and I suspect
that they wouldn't be too difficult.  The greater difficulty is just the
usability decision of determining whether "moving towards" or "moving away" from
an left-left edge would be handled the same as left-right edges.

On "slamming": perhaps, but in general I move a window to where I want it when
it opens, and leave it there.  If I need to move it afterwards, it's usually to
move it out the way of something else, in which case I don't care how much of it
is visible until I move it back afterwards.  But I'm certainly a tiny fish in a
sea of users :)

On infinite resistance : cool, that makes sense I think.  If anything, that
might be another reason to reduce the top edge resistance... seems to me like if
you're using Alt+drag and moving a window towards the top edge, you're *really*
trying to move it off the top of the screen, so it shouldn't be any harder than
absolutely necessary.  (One reason not to do that would be if a significant
number of users habitually use Alt+drag instead of the title bar to move windows
around, but I'm not aware that's the case.)

On hidden edges: if it's not hard to implement it would probably worth a try, to
see how it feels... it's always hard to judge whether behaviours that sound
useful really are until you get to play with them :)

On opposing edges: I think this one's certainly worth a try; I don't think it's
too uncommon to want to line up (say) two terminals or text editor windows one
directly under the other, and it sounds like this would help with that.  I think
 it would be fine just to do it in the off-by-one case, though.  But again, it's
hard to say whether it would turn out to be more annoying than useful without
letting people play with it.

FWIW, another minor annoyance with the current thresholds: the exact size of
Firefox window that I like is about 20 pixels shorter than the distance between
my top and bottom panels, and I like to have it centred between them (i.e.
leaving a small gap above and below the window).   But now I can't position it
exactly where I want to: it  will only let me stick it to the top or bottom
panel, neither of which I like.  

Since this problem is presumably always going to occur to some extent however
small you make the resistance threshold, perhaps there needs to be some keyboard
modifier you can hold while dragging that over-rides the resistance?  (Maybe
even Shift-- is the current Shift-drag functionality still useful with this new
resistance stuff in place?)

Another comment... I wonder if 'on top' windows should only offer resistance to
other 'on top' windows.  In GIMP, for example, I always keep my tool palette on
top, and it feels kind of weird when other things stick to it when I'm just
expecting them to slide right underneath.

I think it is confusing that I don't get the extra edge resistance if I move a
window against the right edge which already extends beyond the bottom edge. 

*** Bug 322753 has been marked as a duplicate of this bug. ***

In the metacity-2.13.2-1 fedora core package, my .02 is that the window edge
resistance feels almost nonexistent, and the screen edge resistance feels like
the delay is too long. I'm not sure if "almost nonexistent" is right; maybe
slightly more? But maybe it really should be difficult to notice.

Also I wonder if the edge should resist as you move past it in both directions,
or only as you move toward it ... ?

Just putting in one vote, this seems like the sort of thing that needs a variety
of people's perceptions.

Why is fedora core using 2.13.2 instead of 2.13.3?

Thanks for the extra data points.  The nonresistant aspect may be the fact that
window edge resistance only exists for opposing edges, e.g. the left side of the
window you are moving only resists against the right edges of other windows. 
Calum brought that up and I wrote a patch to change that (as well as to allow
edge resistance for adjacent windows in his little ASCII example; it's been
sitting on my laptop for almost a week now and I really should upload it).  That
patch seems just a little confusing at the moment because I have a different
amount of resistance for moving towards an edge vs. moving away from one and
that doesn't seem to make sense for e.g. right vs. right edges.  I'm not sure
what the appropriate thing is there.

Fixing up Matthias' point would be really easy and I've also been meaning to
tackle some of the other stuff Calum brought up too.  But I'm not going to have
much time for any of it until the bugzilla upgrade happening this month is
completed that I'm trying to help Olav out with.

First, thanks for implementing this! I've been hoping gnome would get this
feature for some time, and it's great that I can now play with it. :)

Anyway, I noticed something... Let's say I move a nautilus window to the bottom
left corner, and it stops at the edges. I then decide this isn't the optimal
place (e.g. I want to have the window visible and still access the folders I
have on my desktop), and move it along the edge until I'm happy with it's
position, but suddenly the window unsnaps and moves below the panel. This is, of
course, because I can't move my mouse exactly to the right, it's going to be a
bit up or (most often) down as well; and the resistance wears off even if I
don't want that.

Would it be possible to have not only time-based resistance, but a (probably
very slight) pixel-based resistance, too? That way, the required accuracy with
the mouse would be less.

Again, thanks for this great feature!

Pixels are so 1999.

The current edge resistance (in Ubuntu Dapper) still seems to have too much delay. I have to move a window half off the screen to move it off the screen at all. I fear that a lot of people are going to hate that.

Murray: The distance you have to move the window offscreen is nearly irrelevant (other than a small threshold like 16 pixels or so) -- it's the amount of time you have to hold it there.  Also, note that I've been too busy with bugzilla stuff to change this, so it's not a case of changes being insufficient ;-)

Anyway, the whole idea is Fitts's Law--many users would love to be able to slam their windows to screen edges or corners at full speed  (see for example Havoc's comments that I linked to in my blog).  Time-based edge resistance allows that.  I also understand that users aren't benefitting from this due to bad training.  Again, I've covered it in my blog in the original post.

However, I do think that there are quick a large number of weirdo users out there who have a different kind of efficiency they'd prefer.  Namely, shading and minimizing windows is too slow (really small target), so to get windows out of the way, they just throw them offscreen.  Seems like a fundamentally different usage mode that might be worth a pref; but we'll have to think more on it first.

OK. I'll try again when the changes are in. This is so nearly a wonderful experience.

It is not just a matter of inconvenience for people having different habits, but it is also majorly confusing- without knowing about the time delay it is very hard to understand how to move a window offscreen.

If the delay doesn't get reduced or otherwise "fixed", please respect that different people have different habits and add a preference. I'm all for keeping prefs to a minimum but there are limits .. :)

Like I said in another bug it seems to me that the watchword for the default behavior here should be "subtle".

*** Bug 323821 has been marked as a duplicate of this bug. ***

> I do think that there are quick a large number of weirdo users out
> there who have a different kind of efficiency they'd prefer.  Namely, shading
> and minimizing windows is too slow (really small target), so to get windows out
> of the way, they just throw them offscreen.  Seems like a fundamentally
> different usage mode that might be worth a pref;

It's unlikely to be unusual precisely because
a) window-shading is not on by default in metacity.
b) window-shading and minimising leave that small target area compared to a half-off-the-screen window. When you just want to get at a window behind it, it's really easier.

It would be a failure to have a "don't be broken" preference for this.

*** Bug 325019 has been marked as a duplicate of this bug. ***

(Disclaimer: I have not read this whole mega bug, answering to Elijah question in Bug 325019)

>Anyway, Havoc's question is spot on; why disable everything?  Which parts
>actually bug you, Philip? 

What bugs *me* (a lot ;) is screen edge resistance. But I suppose I could even learn to like it if the behavior was more subtle, like the window edge resistance.

As I said on irc, if the idea of a GConf preference is considered, what about storing in GConf the two resistance values instead of a boolean on/off? People who totally hate it could simply turn the resistance value to 0.

I skimmed rapidly through this bug and I don't seem to see this mentioned: would it be possible make the resistance value dynamically dependent on the derivative of the position? I mean, if I move the window fast I encounter less resistance than when I slowly try to place the window near the edge...

Same as Comment #23: The main reason for the patch creation was screen edge resistance. As I said before, the patch can be improved, rewritten etcetera. So I'm pro Paolo's suggestion. Just don't force me to use that screen edge resistance ;-). 

Added Attachment 56436 [details] to Bug 325019.

(In reply to comment #24)
> would it be possible make the resistance value dynamically dependent on the
> derivative of the position? I mean, if I move the window fast I encounter
> less resistance than when I slowly try to place the window near the edge...

The *whole point* of the screen edge resistance as implemented is that it should be there when moving the mouse at maximum velocity.   That's why it's a timeout based resistance instead of just a pixel-distance resistance.  Making it depend on velocity would be a really complicated way of effectively just setting the timeout resistance to 0.

Having a "turn off screen edge resistance" toggle doesn't seem like the end of the world to me.

I don't see any evidence yet that we want to support tuning the exact value - that makes things harder for power users since they have to experiment themselves to find a good value, and harder for regular users since the defaults might never get fixed if all the geeks just tune the value themselves instead of fixing the defaults... just an on/off toggle seems better for everyone... or at most some kind of three-way "off"/"subtle"/"strong" sort of deal.

Honestly I wonder if the "time-based" resistance is really the right approach here.  The intent is to make it easier to align the edge of a window with a screen edge.  In my subjective experience, the time-based resistance is not very intuitive.  Personally, I was not able to figure out on my own that it was time-based, but rather it seemed to me that it was simply set to some hugely insane value for the screen edge.  Further, the "offscreen/onscreen" bit seemed a bit odd to me as well, since it seemed odd that it would sometimes resist going past edges and other times not.

As far a default setting goes, it really goes much too far, and a lot of users are not going to like this at all.  As I've said before the default setting should be very subtle, and the current implementation is anything but subtle.  In all, it's a great theory, but I think that this is an overzealous application of Fitt's law.  This all seems to be based on the overriding principle that people really have a desire to "slam" windows off to the edge of the screen in order to align it there, but I don't see any evidence that this is really the case.  First, do real users actually care if their windows are aligned with the screen edge?  My bet is that either the window is maximized in order to do screen-edge-alignment, or that it's smaller and somewhere in the middle of the screen.  Second, if they do, will they find ramming their windows at high velocity to the edge of the screen the most obvious way of accomplishing this?  This strikes me as extremely unlikely.  In other words, using the time-based screen edge resistance usefully would require training users to do something that is fairly unnatural.

Having a gconf key is probably called for in this case; I like Havoc's off/subtle/strong suggestion.  Strong should be what it is now.  Subtle, the default, should remove time-based resistance and set the pixel-based resistance to something pretty small.

I surely would not complain about an {off|subtle|strong} choice, my suggestion of using a value was related to the fact that I actually like the window edge resistance so I would probably like screen edge resistance too if it didn't punch me in the face every time I try to move a window out of my way :)

That said, given that we are talking about a GConf key, a completely tweakable number just seemed a more logical choice, leaving the liberty to the user to experiment with the value which better suits him. Suggestion for appropriates "subtle" and "strong" value could be documented in the key description.

If we were talking about an UI to put on top of the GConf key I would surely agree that off/subtle/strong or even on/off is the way to go. But we are talking about people who took the time to dig in gconf: they surely read the description of the key they are changing and my guess is that they would more probably be frustrated by fact of not being able to set a "subtle" value which doesn't conform to your notion of "subtle".

> I would probably like screen edge resistance too if it didn't
> punch me in the face every time I try to move a window out of my way :)

Punched in the face??  I really put a lot of effort to try get things to work out right but it appears things went badly wrong.  Sounds like a really nasty bug.  It really wasn't designed to make you feel that way.  I tried hard to make it so that it would be more along the lines of feeling like you had been kicked in the crotch.

Sorry... I just couldn't resist...  :-)

Well (conclusion), if I'm allowed to commit the patch, please tell me. Or commit it yourself. I can easily update my checkout as I'm not doing any further development on metacity at this moment.

(In reply to comment #32)
> Well (conclusion), if I'm allowed to commit the patch, please tell me. Or
> commit it yourself. I can easily update my checkout as I'm not doing any
> further development on metacity at this moment.

As mentioned in the bug where you attached the patch, the pref you add claims it turns the feature off but only partially does so, which is a bug.  Also, I think that the pref, if added, should have only two states -- strong and subtle.  Let us sort that out first.

(In reply to comment #30)
> That said, given that we are talking about a GConf key, a completely 
> tweakable number just seemed a more logical choice

Besides the problems Havoc pointed out, this just simply wouldn't make sense -- how exactly would we map a single number to the edge resistance settings?  We have different behaviors for mouse vs. keyboard moving/resizing resistance; the resistance threshold is different if moving towards or away from an edge; the values are further split depending on whether the edge causing resistance is from another window, a border between xineramas, or a screen border; and finally mouse actions are allowed to have both pixel distance resistances as well as timeout based resistances.  That's a whole heap of values, and while I agree that most combinations probably make no sense, I still have no clue how to map your one value to all those settings.

> I still have no clue how to map your one value to all those settings.

a factor?

Ok, I'll stop being a jerk and I'll let you guy sort it out. As I said I am ok with just an on/off or a tristate or whatever. It's you call.

> Also, I think that the pref, if added, should have only two states -- strong and subtle

Why? We are talking about a *hidden GConf pref*, not about some confusing UI we show to poor users: why make life so hard to someone who just wants to turn the thing off?

(In reply to comment #34)
> > I still have no clue how to map your one value to all those settings.
> 
> a factor?

That would mean that timeout resistance always exists whenever pixel distance resistance does (i.e. whenever the factor is nonzero).  That wouldn't handle requests like Rob's at all (which are definitely the most common requests) and thus this proposal doesn't make sense either.

> > Also, I think that the pref, if added, should have only two states -- 
> > strong and subtle
> 
> Why? We are talking about a *hidden GConf pref*, not about some confusing UI > we show to poor users: why make life so hard to someone who just wants to
> turn the thing off?

Please understand that you are using an early development version of software (granted, it hasn't changed much because I've been distracted with bugzilla for the last several weeks).  I feel that there's a 99% likelihood that the reason anyone wants it turned off at this point is because (a) there is no "subtle" setting, and (b) because that setting (timeout resistance turned off) is buggy and isn't actually subtle enough.  Right now, I think that adding such a pref would be nothing other than a "please turn this bug off" pref, which is about the dumbest kind of pref to have.  _IF_ it later becomes apparent that we can't make a "subtle" setting that is universally good enough, then it may make sense to have an off preference.  But doing so now would be entirely premature, IMO.

Comment #33 part 1: A new patch (Attachment 56436 [details]) also takes into account the resizing. But perhaps I missed yet another part to disable? Let me know if so (I'll update the patch). But let's, indeed, sort out that "strong" and "subtle" stuff first.

Comment #33 part 2: I suggest to use of three or more predefined states. Like "Off", "subtle" and "strong". Perhaps a few more such states. Each such state would now have a predefined set of values. And if it's really important to tweak the values, the real freak can make new such states. A (future) UI could be like the mouse sensitivity preferences (a horizontal scrollbar that scrolls from "off" to "strong"). I don't think such a UI is a necessity.

Created attachment 56687 [details] [review]
Allow edge resistance at both sides

So, I appear to have forgotten to submit this patch to bugzilla and it sat on my laptop since just before Thanksgiving.  Oops.  Anyway, this patch addresses the last issue pointed out by Calum in comment 4.  However, it's a little odd in that moving towards or moving away from don't make any sense yet they do have separate thresholds in this patch.  I can (and should) fix them to be identical, I'm just not sure what the right level is.  Anyone want to do some testing for me?  :-)

Created attachment 56689 [details] [review]
Make extra edge resistance apply even if one edge already offscreen

This fixes the issue pointed out by Matthias in comment 9.

Created attachment 56899 [details] [review]
Remove the timeout resistance

Okay, as pointed out to me by others
  - the timeout is often not long enough if you really want to slam things to the corners for some people; but making it longer would cause further problems given the previous comments (and the issues pointed out below).  So it might be kind of like the auto-raise timeout in that it'd need user-tuning to get right.  But I hate that kind of thing. 
  - the timeout doesn't behave as exactly as I'd like due to the sudden ripping; I'd like something much more gradual after the timeout expired but that'd be a fair amount of work that I don't currently have time for and it reduces the usability of the feature without it (it makes it hard to recognize the resistance as begin a timeout instead of some huge pixel distance)
  - while there are those that have said they liked it, they really haven't gotten the chance to test the subtle setting -- perhaps that would be good enough for the majority of users and I'm just a really small minority.  We probably won't find out unless we switch.  That, and I'd rather be running & testing what I'm most likely to get bug reports on in most cases.  :)
  - and, of course, lots of people seem to hate it, if you couldn't tell by the comments (in bugzilla, irc, forums, whatever) so far.

So, let's just disable it for now.  If needed/wanted, we can always reintroduce it later or add a pref or whatever.

With respect to the patch in comment #39.  If you're going to remove the time-based resistance then you need to substantially increase the space-based resistance for going off the screen.  You should be able to 'slam' a little bit harder without breaking through.

Also: I don't really understand why there is a stickiness when moving a window that's touching the edge of the screen back toward the centre of the screen.

If the resistance-going-off amount is increased then this gives you a large 'virtual area' (if you will) in which you can point to mean "place the window exactly at the edge".  You don't need any additional 'virtual area' on-screen for this and you annoy people who want to position their windows a few pixels away from the edge (even though it is possible if you start from far away and slowly inch towards -- if you accidentally go too far then you have to start over again).  This isn't a huge issue, but why should it be an issue at all?

So in summary:

If you remove the timeout based resistance (and this is a big if, because timeout based resistance is, itself, sort of nice):

Increase the number of pixels required to go offscreen
Reduce (to zero) the number of pixels required to come back onscreen

Created attachment 57077 [details] [review]
Revert to the old edge resistance behavior for keyboard movement/resizing based resistance

This addresses the keyboard related aspects of Calum's points in comment 4 and which I responded to in comment 6.

Created attachment 57078 [details] [review]
Remove pull away resistance

This handle's Ryan's request about pulling window's back away from edges.  It happens to be the same as Calum's final problem pointed out in comment 7, so I think that with this patch I finally have Calum's requests covered -- except that in e.g. the right-right edge resistance case things are still a little messy as I mentioned above (though I'm still not quite sure what to do in that case -- split the "moving towards" resistance in half?  Use the "moving towards" resistance regardless of direction?  Anyway, that's a separate issue)

This patch does trivially conflict with some of the others, but only in the context region of the patch.  Manually fixing up should be easy, as would be manually application since it's so short and clear.

Elijah, your call on these. You know better than I do what the discussion has been and how the code works.

committed them all, then.  :)

This feels perfect to me now. I love you all.

Murray: Even in the case shown in Calum's ASCII art in comment 4?  I was suspecting that people would be annoyed with the current behavior in that case (which has changed since Calum's comment) but I'm not quite sure what is right...

> Even in the case shown in Calum's ASCII art in comment 4?

It's not particularly easy, but if you move slowly enough then there is resistance to allow that. But lining up window corners is not something that I've ever needed to do.

There's resistance -- but only when moving window A to the right after it lines up with B, i.e. only in one direction.  Whether I should make resistance happen in both directions and then how much to have in each direction is what I'm still leaving this bug open for as I don't have any good answers to that...I suspect that current behavior for that particular issue isn't the right answer (though putting resistance in both directions might cause annoyance as per Ryan's "pull away" points in comment 40 and Calum's similar points from near the end of comment 7).   *shrug*

Thanks for the feedback, though, I'm glad to hear the other stuff is all working well.  :)

I tried to do this today and failed miserably... just thought I'd let y'all know:

I sometimes like to have terminal windows exactly as wide as they can possibly be to take up the entire screen horizontally.  It just so happens that 1600 pixels wide seems to be an exact multiple of the font size I use in my terminals.  I like the two window borders to be off of either side of the screen.

Let me quickly explain the one thing left in this bug that's keeping it open:

I need feedback on my "align-windows-above-each-other" (or beside-each-other) shown in Calum's ASCII art in comment 4.  The few people I have asked have shrugged and say they don't use such a feature.  Anyway, the current code only has a uni-directional resistance in such a case (and in the "pull back over the other window" direction, meaning right in that picture) but I don't know if that's what is wanted.  Other possible options:
  - Unidirectional resistance in the opposite direction
  - Bidirectional resistance for such cases
  - Bidirectional resistance, but split the resistance amount in half since it's being used in two directions now
  - Just remove this kind of resistance

Some caveats to keep in mind with each of these options:
  - At least one person has expressed surprise/annoyance that when pulling one window over another there's resistance when e.g. the left sides of the two windows align.  But that's necessary to allow what Calum requested.
  - Allowing bidirectional resistance would re-introduce the problem Calum mentioned in the last two paragraphs of comment 7 (we got rid of that problem by removing the "pull away" resistance, which people didn't seem to like anyway; e.g. Ryan's feedback in comment 40 as well as many things said on IRC).
  - People can still align their windows the way Calum wanted without the resistance on the other edge, by sticking another window up against the other two.  That happens to match how you have to align things in real life anyway, but it may be too much effort if this is a common operation.

Anyway, I really have no clue what to do in this case.

(In reply to comment #49)
> I sometimes like to have terminal windows exactly as wide as they can possibly
> be to take up the entire screen horizontally.  It just so happens that 1600
> pixels wide seems to be an exact multiple of the font size I use in my
> terminals.  I like the two window borders to be off of either side of the
> screen.

That actually sounds more like we need a true horizontal maximization ability.  (We have a horizontally maximize action that is unbound to any key by default, but it doesn't cause e.g. window decorations on those edges of the window to be removed as themes are unaware of the change.)  There may be other similar cases where perhaps we want a timeout or a modifier to allow turning edge resistance off, but I think I'd rather put that in a separate bug at this point if it turns out we really need that... 

Concerning #50, I like the way things work now (as of 2.13.55). I don't think something should be changed, or, at least, I don't know how things could be improved further.

Have you noticed that there is a consistancy problem with this behaviour and Nautilus?

Windows resist each other, and icons attract each other.

I think there is an inconsistancy problem here.

(In reply to comment #53)
> Have you noticed that there is a consistancy problem with this behaviour and
> Nautilus?
> 
> Windows resist each other, and icons attract each other.

Nope.  How do I observe this icon attraction in nautilus?

> Nope.  How do I observe this icon attraction in nautilus?

Try moving an icon 10-15 pixels. It will snap back to its original position.

(In reply to comment #55)
> > Nope.  How do I observe this icon attraction in nautilus?
> 
> Try moving an icon 10-15 pixels. It will snap back to its original position.

Oh, that.  I'll note in iconview in a window (i.e. not the desktop icons but open an actual nautilus window) that you can move the icons hundreds of pixels and they snap back.  This doesn't seem relevant to how window movement on the desktop occurs.

Also, the snapping of the icons on the desktop doesn't happen until after the icon is released because of the fact that there are a small (relative to number of pixels on the screen) set of valid locations for icons to be placed.  Again, this doesn't seem relevant to how window movement on the desktop occurs -- virtually all pixel locations are valid.

So, in summary, I see no inconsistency.  That's my opinion, anyway.

(In reply to comment #28)
> at most some kind of three-way "off"/"subtle"/"strong" sort of
> deal.

I think a "strong" option would be desirable for people with RSI, arthritis, or generally poor motor skills. For many people it's easier to make big movements with the mouse, it's small and slow movements that are painful, hard, or impossible.

The 'strong' option was really the basis of my comment #4, where I suggested the amount of resistance might be some factor of the (user-definable) gtk drag threshold, which users with impaired motor skills might also need to adjust. 

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.