SUMMARY In KWin version 5.23.5 and older, you could enable 'Display when moving or resizing', in regards to the window geometry. After upgrading to 5.24, this option disappeared, and along with it the functionality. The only package that seems to have been removed is `libkwin4-effect-builtins1`, which is still at version 5.23.5. I don't know if this is an intentional feature removal (I *really* hope not) - like if the effect is no longer compatible with some changes to KWin under the hood - or if the package was simply forgotten about and not upgraded within KDE Neon's package repository. I also don't know for sure if the package in question is even responsible, just that it's the only package that the upgrade removed, and it seems to be KWin related. STEPS TO REPRODUCE 1. Enable the option before upgrading, located in the 'Movement' tab of the 'Window Behavior' page of System Settings. Optionally, test and make sure it works by dragging a window around or resizing it. 2. Upgrade KDE Neon's KWin package from 5.23.5 to the latest version (5.24.1 at this time). 3. Open up System Settings again and look for the option, finding it missing. 4. Might need to log out and back in first, but after upgrading KWin try resizing or moving a window around again. The window geometry information will no longer show. OBSERVED RESULT The option to enable this feature is now gone. Additionally, windows move around and resize as expected, but without showing the width/height/position of the window, and without showing how much the window has grown/shrunk/moved on each axis. EXPECTED RESULT The option to enable it should still be present, and moving/resizing windows should still show the size/position/etc. of the window that's being moved or resized. SOFTWARE/OS VERSIONS KDE Neon User Edition.
*** This bug has been marked as a duplicate of bug 443723 ***
(In reply to Patrick Silva from comment #1) > > *** This bug has been marked as a duplicate of bug 443723 *** That is not the same bug at all. I'm under X11.
read bug 443723 comment 2
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.
(In reply to Patrick Silva from comment #3) > read bug 443723 comment 2 Yeah, I noticed that after I responded. Either way, I do not believe the fact it was mentioned constitutes it as reason enough for it to be considered the same bug.
I'm missing this feature on X11 very dearly as well.