https://bugs.kde.org/show_bug.cgi?id=450629
--- Comment #4 from Colin Griffith <tyna...@gmail.com> --- Ah, I see that the removal of the feature entirely was mentioned in the comments of that bug. I'm not sure that really constitutes it as the same bug, though, so I still don't believe this should be considered a duplicate. Furthermore, I have much less niche and much more ordinary use cases for this feature - and in a way it could be considered an accessibility feature (which of COURSE are going to be considered niche; that doesn't mean they aren't useful for a large number of people.. You'll be getting more complaints about this once distros other than Neon start packaging 5.24.x, I can guarantee it). Here's the comment I wrote on the merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/1826): > @vladz, I just found this merge request while doing more research for the bug > report I just filed (https://bugs.kde.org/show_bug.cgi?id=450629). > > I'm a developer, but that's not why I used geometry information. My hands are > kinda unsteady (not because of any physical issue, but because I'm just not > good at visualizing how my hand is moving relative to the cursor on my > screen) and I often find myself overshooting where I want to place a window, > or what size I want the window to be. Interactively seeing the difference in > size now compared to before helps me know how much to compensate for my hand > missing the mark. > > For example, lets say I want a window centered on the screen. Obviously I'll > have 'Center snap zone' turned on, lets say equal to the other snap zones (so > 10px). So to center the window, I first drag it along the top of the screen > until it snaps to the middle of that... But then I have to carefully lower > the window from that snapping position to the middle of the screen. > > Before, I could simply drag the window to the top-center of the screen, > release after it snaps, then start dragging it again downward... And watch > the numbers, making sure they don't overshoot +10 or -10 pixels. > > Nowadays, I have to very caarreefully drag the window as slowly as possible > (there's a button on my mouse that's thankfully dedicated to making it move > slower, but then sometimes the act of lifting the mouse and putting it back > down to drag further still makes it go too far in one direction or another), > and even then I find myself very frequently missing the mark. > > I also use it for resizing windows; sometimes someone shares a picture or > video with me and I just have an extreme preference for watching them in > their original resolution. However, I also have a passtime of converting gifs > to mp4 files for Telegram users and I tend to use a max resolution of > 448x448, but keeping aspect ratio.. So after I watch some other video, > returning my video player to display an exact 448x448 requires me to load up > one of my previously converted gifs that's taller than it is wide, have the > video player show it at 1:1 scale, and then manually scale the width of the > window to 448px across. > > This is no longer possible, and I instead have to hunt down a gif I converted > that happened to already be a perfect square. This usually takes several more > minutes than if I could just see the size of the window while I was resizing > it. > > This has been an extremely frustrating downgrade, but I do see that your goal > in this removal was to simplify the code, make it more performant, and work > toward fixing buggy aspect-locked window handling (such as mpv) in Wayland. > As much as I hate the removal of this feature I frequently use every day, I > have to admit it's warranted. I hope it can be re-implemented in some way in > the very very near future, though.. I don't currently know of any other way > to cover my use cases. -- You are receiving this mail because: You are watching all bug changes.
