https://bugs.kde.org/show_bug.cgi?id=489746
pallaswept <pallasw...@proton.me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pallasw...@proton.me
--- Comment #5 from pallaswept <pallasw...@proton.me> ---
Problems:
I think it's important to consider, what happens to a user who does NOT want
their maximised window to stay maximised when they move it? As it is now, the
state of the window is determined by the user's actions. How can that be true,
if the maximised windows, stay maximised? If this request were implemented, how
might a user drag a maximised window to somewhere else where they do NOT want
it to remain maximised?
Fixing problems seems easier, if we don't worry about creating new problems
with our solution. Just ask Queensland about Cane Toads :D
Not problems/user error/edge cases:
As it is, this is mostly * working fine here. If I drag a maximized window, it
restores it, If I drag it to a position where it should maximize it, it does,
if I don't, it doesn't. If I drag a vertically maximized window horizontally,
it stays vertically maximized UNLESS I drag it away from the vertical edges and
then it restores it. Same if you swap horizontal for vertical. Pressing esc
during the move cancels it (unless I'm moving by holding meta and then the
system monitor opens, annoying). It seems pretty much good.
The one part that makes this * mostly is that if I do this on multi-monitor,
and the screen edges are not aligned, then it fails as so:
When I drag a vertically-maximized window to a horizontally misaligned window,
the window is un-maximised, or
When I drag a horizontally-maximized window to a vertically misaligned window,
the window is un-maximised,
Because the window leaves the screen edge when it leaves the screen.
And there's no mechanism to vertically- or horizontally-maximise a window while
dragging, so I can't drop it in the same state it was when I dragged it.
Of course, with fully maximised windows, that's not a problem, because there is
a mechanism to drop it in the same state it was when I dragged it (drag it
beyond the top edge). So, the only time there's really a limitation to this is
vertically or horizontally maximized windows.
>see Fitt's law; if I just want an unmaximized window at the top of the screen,
>the target has infinite size if the automatic maximization feature is disabled,
I can't reproduce this. If this feature is disabled, now we can drag the window
beyond the edge of the screen, so the target is not infinitely large, it is
infinitely small, because we have to hit that single row of pixels, the top of
the screen, in order to leave the window there.
Of course, there's snap to edges, which would help us hit that row, but you
already can't hit that reliably and report accidentally dragging it too far,
and turning the 'maximize on top edge' feature off does not prevent that, it
just means that when you do drag it too far, rather than maximising, you just
drag it off screen. Neither setting it on or off can compensate for dropping it
in the wrong spot and give the result you wanted. You need to not drop it in
the wrong spot.
> but a smallish finite size if it's enabled.
You can configure that size to be one that works for you, large enough to avoid
accidents.
> But with the new behavior, if I move the mouse somewhat vertically, the
> window becomes vertically unmaximized,
This is the same size defined here as "somewhat". You can make that "somewhat
larger" :) if it's too small for you, which, if you're doing things by
accident, it is.
FWIW this is probably because the default sizes are absolute, in pixels, rather
than relative, eg percent of screen, so pixel density has a direct relationship
to the accuracy required of the user... as in, if you have a higher-res screen,
the snap-to zones are effectively smaller.
This is a very real problem with mixed density displays, because what is a
comfortable/practical snap distance on one screen, can be
uncomfortable/impractical on the other.
I'm guessing that's why the default is quite small. Having it large enough for
high-DPI displays renders it unusable for everyone else, so we all get the
'lowest common value'
Watching your video after writing all that, snap distance is *definitely* your
issue. Your snap-to distance is smaller than you are able to maintain accuracy.
When you move "horizontally", you have a vertical error greater than the snap
distance, so you are un-snapping it. It's doing exactly what you told it to do.
If (like me!) you can't/don't want to be more accurate, just make snap distance
bigger so you don't tell it to do that. You can rely on automatic snapping, or
manual accuracy, but using neither and hoping for a good result is hoping for a
mind-reading computer. Give it a few more years :D
Possible Solutions: (probably need all of these to solve all the above)
* Window snapping distance should be a relative measure, eg scaled screen
percentage, not absolute, eg pixels.
* Pressing esc while moving by holding meta, should not trigger the meta+esc
keybind. Meta+click+drag+esc is not meta+esc.
* There's an easy way to approach all of these issues, whether inaccurate
movement, multi monitor, heterogeneous density, etc... Allow a keybind to
control edge snapping/maximising during moves, just as there is one for tiling
(shift+drop). Alt doesn't seem to do anything, if I'm not mistaken? How about
that?
* Related to the above, the astute observation that
> The behavior thus depends on not just the start and end points of the
> dragging, but the path the cursor takes between them
Suggests that maybe this would work better if only the end point were
considered. I feel like this is the trick, but going back to the start of this
message - maybe there is a use-case for considering the entire path? I can't
think of one.
--
You are receiving this mail because:
You are watching all bug changes.
