Upon further experimentation, it seems the issue may not be restricted to multi-monitor setups.  Maximized windows get restored as soon as any border of the window leaves a screen edge, so even dragging them within a single monitor is problematic.

Created attachment 171841 [details]
Screen recording illustrating moving vertically maximized windows, and completely maximized ones between screens

(In reply to Tristan Miller from comment #1)
> Upon further experimentation, it seems the issue may not be restricted to
> multi-monitor setups.  Maximized windows get restored as soon as any border
> of the window leaves a screen edge, so even dragging them within a single
> monitor is problematic.

I guess this is intentional, based on the logic that, at least with one screen, there is rarely a point in moving a maximized window without unmaximizing it. But I don't like it either, because I liked to drag maximized windows between screens.

What I find even more problematic is that windows that are maximized in one direction also get fully unmaximized when dragging them in that direction. With wide screens, it often makes sense to use vertically but not horizontally maximized windows, and sometimes to drag them in the horizontal direction. But with the new behavior, if I move the mouse somewhat vertically, the window becomes vertically unmaximized, and stays so even if I move the mouse back to the original vertical position before releasing it. The behavior thus depends on not just the start and end points of the dragging, but the path the cursor takes between them, and one has to pay attention to moving the mouse somewhat precisely horizontally. (See screen recording, showing moving a window by its title bar, via Meta+drag, and via dragging empty space in the window.)

In the case of fully maximized windows, the new behavior nicely complements the option to maximize windows by dragging them to the top of the screen, and if you want the window to be maximized after dragging it to the other screen, you can achieve it relatively easily. (Except if multiple screens are arranged on top of each other, in which case maximizing by dragging to the top can't be used on the bottom screen.) So one solution would be to combine the unmaximization of fully maximized windows by dragging them, and the maximization of windows by dragging them to the top, into a single toggle, while reverting to the old behavior in the case of partially maximized windows. Alternatively, if some people like the new behavior, you could add separate options to disable unmaximizing fully maximized and partially maximized windows by dragging them.

(I disable the option to maximize windows by dragging them to the top of the screen because it often ends up accidentally maximizing windows I just want to put at the top of the screen—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, but a smallish finite size if it's enabled.

And anyway that feature doesn't help in restoring the size of a window that was only maximized in one direction, and is accidentally unmaximized.)

Any attention to this is appreciated!

Workaround that may help some people: you can assign shortcuts (Keyboard -> Shortcuts -> System Services -> KWin, "Move Window to Next/Previous Screen" and the windows will preserve their maximized state. Doesn't solve the problem when you are using the mouse, but it's better than nothing.

Really hope an option can be created to get the old behavior back -- the best thing about KDE (for me) is being able to shuffle windows from screen to screen really fast, and the new behavior is a huge friction point for that.

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.

(In reply to pallaswept from comment #5)
> >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.

If I'm dragging a window by its title bar, I can't drag it past the screen upwards*. That, combined with window snapping, means that with automatic maximization disabled, dragging a window upwards arbitrarily much puts it exactly at the top of the screen.

* Except if there's another screen arranged above it. (I logically arrange my screens side-by-side for this and similar reasons.) But if there's another screen above it, the automatic maximization doesn't work either even if it's enabled, so that's another problem with the idea that if you want to maximize the window again, you can do it easily.

> > 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.

Where? With automatic maximization enabled, windows get maximized as soon as the mouse touches the top of the screen. In the Screen Edges kcm, where automatic maximization can be enabled, there are no setting to adjust that. The smallish finite size you need to hit to drag a window to the top of the screen when automatic maximization is enabled is about half the thickness of the title bar (the distance between where you grabbed it and its top edge) or the snap zone, whichever is thicker. The only ways to increase it is to use huge title bars (taking up space) or huge snap zones (at some point getting in the way of being able to freely arrange windows).

> 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.

Where? I've not seen any settings related to this new automatic unmaximization feature. (It doesn't use the window snapping zone set in Window Behavior / Movement. The "somewhat" is actually bigger than the window snapping zone, but still small enough that I sometimes accidentally trigger it when dragging vertically maximized windows over a long distance between two screens arranged side by side. In the video I of course triggered it intentionally to demonstrate it, I'm more accurate usually, but I've occasionally triggered it unintentionally.)

> 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

What I'd like is quite the opposite: don't maximize or unmaximize windows (fully or in one direction) unless I explicitly trigger it with the appropriate button/shortcut/double click, just like it behaved until recently.

> > 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.

That would more-or-less solve it for vertically (or horizontally) maximized windows: if you accidentally unmaximized it by moving it vertically, you could still undo it by moving the mouse back to approximately the same vertical position as you started with before releasing it. Though I'd personally probably still slightly prefer vertically maximized windows to move but stay vertically maximized when moving them in any direction (a use case being to quickly move a window out of the way by dragging it in an arbitrary direction to see another window and possibly click something in it, and then moving it back); it's slightly weird that vertical maximization can be toggled in one direction by dragging a window but not in the other direction.

For fully maximized windows, we could have them unmaximized as long as they stay on the same screen, but maximize them immediately if the cursor is dragged to another screen (regardless of where they are released), since that suggests that the user may have intended to just drag them to another screen without unmaximizing them, while there's no point in dragging within the same screen if you don't intend to unmaximize. Though that behavior could be seen as weird too.

Another solution, of course, would be to allow turning the current, new behavior off as I suggested, either as a separate option or tied to the automatic maximization option.

For me the ideal, and simplest, solution is that besides the current option "Activate, raise and move" there would be an additional option "Activate, raise and move (preserve maximized)". You could assign a different modifer key to each and pick one according to your needs in the moment.

In other words: an option to restore the previous behavior, even if it's not the ideal one-setting-works-for-everyone approach; it seems like a "don't let the perfect be the enemy of the good" solution.

I don't use any snapping or automatic maximization -- can't stand it -- and the advantage of the old behavior was that you could move windows between screens with lightning speed: hold down Meta and make a quick left-drag darting movement and the window snaps to the other screen; takes like 50ms to execute, no time spent finding snap-to target areas or window edges, etc. You could quickly reshuffle your entire arrangement of windows over three monitors in about 1 second. Non-maximized windows went where you put them, maximized windows obediently went to the screen you dropped them on.

Let's try this again....

OP reported this problem:
> need to manually maximize the window again.

This sucks and we all agree this sucks and is a problem. 

Operative word:
> manually

The problem is the unnecessary requirement for manual intervention.

In natural terms:
"Maximise, move, maximise again"
Sucks. We want:
"Maximise, move"
and then.... *do nothing, because it's still maximised?* 

Right? 


Right??




Wrong. This is where this conversation departed from our intention. We only really care about:
"Maximise, move"
and then.... *do nothing*. 

That last part above, "because it's still maximised", is just one imagined means to the end. And it's not a good one.
In fact, sometimes we (KDE users, obviously none of you specifically) specifically want the availability of:
"Maximise, move"
and then.... *do nothing, because it's *not* still maximised, it's in some other state we just chose on purpose, during the move* 

If a solution does not accommodate that, it's not any good. It would break more than it fixes. 
OP asked for this solution:
>  windows should preserve their maximization status when dragged to a new screen

This is not the way to fix that problem. This is focussing on "still", not on "do nothing". We don't care if it's "still" maximized. We care if we have to "do nothing". If we force "still maximised", we fix one thing, and break several others.

What if we want to drag a maximized window into a tile on the other screen? What if I want to drag my partially maximised window to fully maximized? Maybe I have something tiled to the left side and I want to move it to the centre now...Or back the other way? What if I start doing one thing and then change my mind? Now for every one of those (and many more), the maximisation state has been preserved, which was, to quote OP
> not what I want
and I have to 
> manually 
"do something" after the move, and they all are problems that suck just *exactly* like this does. But now there are *more* of them. That 'solution' only makes things worse. It doesn't resolve this problem, it multiplies it, and spreads it to everyone.

I don't actually believe it is anybody's intention to basically say "this sucks for me, so fix it for me, and make it suck for everyone else", but that's what's been happening here so far. 

We all have lightning-fast moves that leverage Fitts' Law to provide ease of use, right now. Preserving maximisation state during moves, breaks that. It's not viable. It's just not. That doesn't mean give up, or leave it broken, it means we need to find something else. It seemed like a good idea, we looked closer, we see that it is a bad idea. 

Let's move on from that idea, so we can find one that does work.

(In reply to pallaswept from comment #8)
> But now there are *more* of them. That 'solution'
> only makes things worse. It doesn't resolve this problem, it multiplies it,
> and spreads it to everyone.
> 
> I don't actually believe it is anybody's intention to basically say "this
> sucks for me, so fix it for me, and make it suck for everyone else", but
> that's what's been happening here so far. 

I never asked for forcing my preference on everyone. I'm just asking for making it configurable; it's fine if the current behavior remains the default. In case you're opposed to make it configurable because you don't want to clutter the settings with even more options, tie it to maximizing windows dragged to the top edge, turning it into a "maximize by dragging to the top edge, unmaximize by dragging maximized windows" option: the people who like one are probably more-or-less the same people who like the other.

> What if we want to drag a maximized window into a tile on the other screen?
> What if I want to drag my partially maximised window to fully maximized?
> Maybe I have something tiled to the left side and I want to move it to the
> centre now...Or back the other way?

I don't use tiles, and I don't try to maximize, unmaximize or otherwise resize windows by dragging them.

(In reply to pallaswept from comment #8)
> OP asked for this solution:
> >  windows should preserve their maximization status when dragged to a new screen

It appears you have (deliberately) quoted my words out of context in order to make it seem as though I insist on imposing a certain behaviour on all users.  Please don't do this.  The full sentence of mine from which which you produced this misleading extract is as follows:

> Could you please either restore the original behaviour, or add a
> configuration option to System Settings that allows the user to
> determine whether windows should preserve their maximization status
> when dragged to a new screen?

(In reply to Grósz Dániel from comment #9)
> I never asked for forcing my preference on everyone. I'm just asking for
> making it configurable; 

That's the same thing. If you 'make it configurable', then you are leaving the people who toggle the solution off, with the bug. There is an actual problem that needs fixing, here. 

> it's fine if the current behavior remains the default.

No, it's not, because it's broken. I had assumed it was not intentional, but you're still doing it. Is your whole attitude truly deliberately based on "screw those guys, just fix it for me?"

> I don't use tiles, and I don't try to maximize, unmaximize or otherwise resize windows by dragging them.

You are not the only KDE user on the planet. These are but a few examples of many important use-cases that are the default, very widely used anyway, and would be broken by this non-solution. 

(In reply to Tristan Miller from comment #10)
> (In reply to pallaswept from comment #8)
> > OP asked for this solution:
> > >  windows should preserve their maximization status when dragged to a new screen
> 
> It appears you have (deliberately) quoted my words out of context

I'm quoting something from the exact same page. You're not being misrepresented.

Perhaps its best you don't try to assume my motives.

> in order to make it seem as though I insist on imposing a certain behaviour on all users.  Please don't do this.

No, it was just because the unquoted text was irrelevant and this thread seems to be having trouble grasping even simple concepts, so I'm simplifying.

You're still arguing about it RIGHT NOW. You seem pretty insistent to me. You can feel free to stop any time, and instead, discuss a solution that would work. 

> The full sentence of mine from which which you produced this misleading extract is

At the top of this same page.

The parts I didn't quote, weren't relevant. I was quoting the part that encapsulated the fix you suggested, because I was discussing the fix you suggested. The parts I didn't quote, but you did, were:

Making it configurable: Leaves the bug in place for those who don't configure their machine as you would. See above. 
Rolling back: Breaks mostly-working feature for everyone else by removing instead of fixing it.

So, thread.....Can we discuss fixing this, yet? You know like, actually fixing it, so it's fixed, for everyone who suffers from it, and not only for certain individuals with certain use patterns or certain configuration options?

It may be inevitable that either certain actions are easier to perform and others slightly more difficult (require two steps or a keyboard shortcut, or require more precise mouse use), or the latter are easier and the former slightly more difficult. And different people prefer different tradeoffs. And IMO that some actions are slightly more difficult to do is not a buggy or broken behavior, just a possibly necessary tradeoff. As such I don't regard either the current or the old behavior as broken, just as different tradeoffs.

Now if you can invent a behavior that's superior to both the current and the old one (e.g. it's as easy to move a maximized window to a different screen while keeping it maximized as with the old behavior or almost so, and as easy to unmaximize a maximized window and move it to an arbitrary position as with the current behavior, or almost so), I'm all for it! And the ideas discussed towards the end of Comment 5 and Comment 6 are in that direction.

pallaswept, are you a KWin developer looking to make a decision based on this discussion, or a user? If the latter, I don't see much of a point in continuing this discussion until a developer who considers implementing some change to the current behavior shows up, though of course if you have further concrete ideas, you should post them.

> if you have further concrete ideas

Concrete ideas is why I'm having this conversation exactly. When a dev who wants to fix this - which I have considered, but is likely not a good job for a part-timer guest dev because plasma drag'n'drop has a lot of moving parts -  but when someone looks at it, they're going to need at the very least a concrete definition of the problem, and it will help them a lot if we could actually tell them what we'd like them to do about it, because then they don't have to imagine something up and then bounce ideas back and forth like we are now.

Put simply, they can't fix a problem if we can't tell them what the problem is, and so far, we can't.  

Don't get me wrong, I feel it the same as you do - that's what brought me here... but computers aren't smart, we need to feed them exact instructions on how we want them to act, so we need to define the old, new, and desired behaviour, in a very specific manner, more than enough for a human to 'get it', enough for a stupid computer to follow instructions. That's why I made a fuss about "don't just preserve the window state" because to us intellectually gifted human types, that's a good way to describe it, but if we think about how a computer would interpret those instructions, we can see that it's gonna break stuff.

So, as for a concrete definition of the problem:

It's not that the window state is no longer preserved, because it wasn't preserved before. I've spun up a VM with 6.0.4 (the oldest 6.0<x<6.1 version I can find in a live ISO - ultramarine has it at present, if you want to try that. So does garuda but theirs is heavily customised) and it acts like it does now - as soon as you start to move the window, it immediately un-maximises it. It wouldn't even allow me to vertically or horizontally maximise it (I usually do this by doubleclicking one of the sides/top/bottom - how did you do it in 6.0.5?) so that I could test moving windows on a single screen.

Speaking of single screen, that's another good example of how we could be more 'concrete' in our definition. The original report was that it was a problem with moving between screens, but as was noted above by others, it also effects semi-maximised windows on a single screen. Once we un-snap it (which seems to be happening even to those of us with snapping disabled? Not sure - that's another thing that needs a 'concrete' definition) it resizes and never returns to the previous geometry... and I can't reproduce it on 6.0.4 at all because I can't even get that semi-maximised geometry in the first place.

So... yeh it would be good I guess, to start with a more solid definition of the problem. Which is a lot more complex a task, than it sounds... I could use your help there. I've often been annoyed by maximised windows, moving them, and then having to maximise them again, the same problem this issue describes. (also, it can be annoying that it resizes the window mid-move and reflows the contents but that's another story) The difference is, for me, it's always been that way. And rolling back to a version matching this report, it still seems that way. Can you explain what's missing here? Perhaps it's a certain setting you're all using and I'm not (and isn't default)?

I have the exact same problem. My main monitor is 4k, my secondary monitor is 1080p, when I drag a window from 4k to 1080p I can only see "one quarter" of it. I have to take extra steps to maximize it/extra clicks. I've migrated from X11 to Wayland recently, and I don't remember this happening before.

(In reply to lucasfbustamante from comment #14)
>  I've migrated from X11 to Wayland recently, and I don't remember this happening before.

That's interesting. Maybe that's why we can't reproduce the old behaviour that others remember? I only tested the stock setup, which means Wayland. Maybe the behaviour you remember was X11-only? Can you reproduce it? How does it manage allowing users to *not* keep maximised state when moving?

(In reply to pallaswept from comment #15)
> (In reply to lucasfbustamante from comment #14)
> >  I've migrated from X11 to Wayland recently, and I don't remember this happening before.
> 
> That's interesting. Maybe that's why we can't reproduce the old behaviour
> that others remember? I only tested the stock setup, which means Wayland.
> Maybe the behaviour you remember was X11-only? Can you reproduce it? How
> does it manage allowing users to *not* keep maximised state when moving?

I've always used X11 and still use it, and the change happened anyway. I don't know if maximized windows stayed maximized on Wayland before 6.1, but they did so on X11 and now they don't, so it's not simply resulting from switching from X11 to Wayland.

(In reply to Grósz Dániel from comment #16)
> they did so on X11 and now they don't

Right, this is what has been said before, but even when using the old version, we have not been able to demonstrate that it ever worked that way; nor how it deals with the use-case of intentionally moving a maximised window to a non-maximised window.

It seems like what you're observing is X11-specific, because it has never worked that way on Wayland... at least, not in my tests with the versions reported, or in my memory before that.

So, for you, it is a change in the behaviour of X11 kwin, for lucas, it is a change between X11 kwin and Wayland kwin, and for me, it is just normal Wayland kwin behaviour. 

We still don't know how it handles when the user wants to move a maximised window to a non-maximised window. We could try that old version of kde, but with X11 this time... but I can't spin up VMs right now (selinux problems here) would you mind doing the test this time?

Since there's some confusion, I've circled back to this to be more diligent in my bug report, and I step back on what I said. I have a triple monitor setup, and up until pretty recently I've had 2x QHD and 1x FHD. Last week, I switched to 1x QHD, 1x 4k, 1x FHD.

When I move a windowed window from 4k to FHD I usually have some trouble fitting that in, and that's the behavior I'm describing. I've used X11 with this 4k only for a couple of hours before I switched to Wayland, so I might not have noticed that it also behaved similarly, as this issue wasn't so apparent when using only QHD.

I've logged back to X11 and noticed it had the same behavior, but the "maximize preview" made it more intuitive when an window had "snapped" to the top to be maximized, whereas in Wayland I kinda have to guess if it's "snapped" and I often miss it for some reason. I'm looking around as I'm pretty sure this is all configurable, so just wanted to make this correction from my end here. There is no expectation from me that when dragging a full screen from 4k to FHD it remains full screen, but it seems to be indeed hard/could be more intuitive to snap windows to be maximized when dragging to top.

(In reply to lucasfbustamante from comment #18)
> in Wayland I kinda have to guess if it's "snapped"

That would be difficult. For me, when I am going to snap to a side or corner area, or a tile, I see a darkened area with the geometry the window would have if I drop it. Is that the 'maximise preview' you mentioned? Is it not working for you on Wayland, or just working different?

I wonder if you're referring to the fact that you can't see that 'maximise preview', because it is completely hidden behind the window you're moving, when that window is larger than the desktop you're dropping it to (such as when that window was a larger windowed window on QHD/4K monitor and is being dragged to a FHD monitor).

> I wonder if you're referring to the fact that you can't see that 'maximise preview', because it is completely hidden behind the window you're moving

Yes, exactly. The window I'm trying to snap is bigger than the screen, so it covers everything and the "fade" effect on the sides is not visible.

X11 on the other hand shows a rectangle border over all edges of the monitor that overlaps the window, think of it like a bigger z-index if it were CSS. The result is subtle, but often when I drag a window from 4k to FHD, it doesn't "snap" and I have to re-drag it to make sure it's maximized.

(In reply to lucasfbustamante from comment #20)
> X11 on the other hand shows a rectangle border

I can replicate that 'oversized window blocks the faded rectangle' here. I didn't know that X11 did that outline above the window. I think that might be a different issue to the one we've been discussing so far (especially since that even applies on single screens with vertically maximised windows). Although, there might be some crossover. 

Even if we can't see the rectangle where it will drop, courtesy of Fitts' Law, combined with a configurable snap zone size, those targets are usually pretty big, and it should feel fairly natural, to just drop it 'by feel' ...but as I mentioned above, because the snap size is set in an absolute measure of pixels, it can be impossible to find a good value where display resolution differs greatly. So, if you get the snap size correct for your 4K screen, then it might be too big on your FHD screen (or vice-versa), and you mightn't be able to casually drop it in the right place and get a predictable result. Like you said, it's less apparent with QHD, because the resolutions differ less, so the snap regions are more similar in size.

So yeh, some relationship exists, but it sounds like it would be worth filing a separate issue for the missing border.

(In reply to pallaswept from comment #17)
> We still don't know how it handles when the user wants to move a maximised
> window to a non-maximised window. We could try that old version of kde, but
> with X11 this time... but I can't spin up VMs right now (selinux problems
> here) would you mind doing the test this time?


It's not even clear what you want us to test. "Start dragging a maximized window by its title bar" is a concrete action, and AFAIUI you'

(sorry, sent prematurely)

(In reply to pallaswept from comment #17)
> We still don't know how it handles when the user wants to move a maximised
> window to a non-maximised window. We could try that old version of kde, but
> with X11 this time... but I can't spin up VMs right now (selinux problems
> here) would you mind doing the test this time?

It's not even clear what you want us to test. "Start dragging a maximized window by its title bar" is a concrete action, and AFAIUI you've claimed that on Wayland it unmaximmized the window even before 6.1. "Want to move a maximised window to [become?] a non-maximised window" is not a concrete action sans mind-reading, and I'm not sure what concrete action you have in mind.

Again, pallaswept, are you a KWin developer or not?

(In reply to Grósz Dániel from comment #23)
> Again

My answer is still the same. 

Regarding the testing required: Feel free to exercise your initiative. Anything that will define the problem, would be good - presently we don't have a definition of the problem, so it is not possible for anyone to develop a solution.

(In reply to pallaswept from comment #24)
> (In reply to Grósz Dániel from comment #23)
> My answer is still the same. 

Sorry, I missed it in Comment 13.