https://bugs.kde.org/show_bug.cgi?id=489746
--- Comment #13 from pallaswept <pallasw...@proton.me> --- > 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)? -- You are receiving this mail because: You are watching all bug changes.
