I’ve recently performed the most current Manjaro updates and am now unable to correct what is for me, literally the most annoying behavior change that could have occurred making Manjaro act like windows in its crappy scaling/snapping behavior.
Previous Behavior: (desired)
When snapping windows to the screen edge ((top/middle/bottom) left/right) the windows would take up half the screen size by resolution (not affected by other windows being snapped) (neither would resizing these windows result a sizing change to other windows snapped or not (ie would only affect the window you’re re-sizing))
Now when snapping windows, the current x resolution of the window is maintained with y taking up the correct spacing (y adjusted dependent upon which snap direction) however if another window is snapped the remaining space will be occupied. (further re-sizing snapped windows now affects the sizing of the other snapped windows simultaneously)
Question being: how do i reverse this without downgrading, I can’t find anything in settings and neither can I find anything in the three most recent release notes for KDE that have been applied to manjaro, is a bug of something? please help
i have no idea what your actuall issue is… post picture of it…
and since it started to happen after last update, create a new test user, reboot, log in with the test user and see if it has also the same issue …
this is a wise tip. it’s always better to create a test-user and play around new gui-gigs. this doesn’t harm your system and you can easy delete a broken test-user account and you can take changes to your original account once you checked that the changes do work.
Sorry for the late reply, have been held up for a bit.
In relation to creating a new user, I did so, the same behavior is displayed by default. Personally I care not to create another user to test changes on, I’d rather do it on my primary user as easier.
In relation to screenshots, I’m not 100% on how I can create screenshots to exactly show this but I’ll have an attempt in a bit.
To better explain the behavior and also point out the location where the settings for the behavior are.
In settings > Workspace Behavior > Screen Edges
Tile: Windows dragged to left or right edge
The above setting results in the following
You grab a window title bar
Drag that window against the edge of your screen, left or right
The window then is adjusted to be the height of the screen and half the width of the screen. for example
A window (1280x720)
A screen (1920x1080)
The window becomes (960x1080) (if it had been dragged to the left, the window x.pos would be 0 else if to the right the window x.pos would be 960)
The new behavior is
A window (1280x720)
A screen (1920x1080)
The window becomes either
If there are no other snapped windows (1280x1080)
If there’s another window, (the available space that the other window doesn’t take up x1080)
In relation to the new behavior, I’ve had a look through everywhere I could and played around with numerous settings to no avail, prior to this change, I had not modified any of my settings for a number of months. This setting changed after last nights (i believe) updates.
No settings in the Screen Edges page changes the new behavior (I’ve tried them all) and I can’t find anything relevant else where.
I took some pictures and tried uploading them, but the forum responds with a message saying “An error occurred: Sorry, you can’t embed media items in a post.”. Idk what’s up, perhaps a restriction for a new account?
Also another behavior change I’ve observed relating to windows scaling/sizing
If you snap a window to half the screen, re-size that window, drag that window out of scaling mode and snap a different window, that new window will be scaled to take up the space that would have left available by the last snap re-sizeing (kde now acting like a hybrid tiled window manager with static scaling? for window edge snapping)
Also now when unsnapping windows, they don’t maintain their new size as a result of being snapped, previously the size change as a result of snapping was a persistent change until other action is taken to update the window size
Window is: 1280x720
Window Is snapped to the left half the screen: 960x1080
Window is resized to 500x1080 while in snapped state
Window is dragged out of snapped state (window changes back to 1280x720)
Another window is snapped to the right half of the screen (window now is sized at 1420x1080 despite no other window being currently snapped)
The more I look into the new behavior the more it seems like a permanent change to kde window management, Being there’s a lack of settings for this and it being more Windows like, I have a feeling there won’t be anyway to revert this behavior.
Thanks for the guide on screenshots, I’ve added what I wrote up below along with the screenshot links.
I’ll also mention, I’ve had a look around at the new tiling settings/features now that I’ve realized they have been added and have found that while I can make the layout visible and use the layout by holding shift, I can’t access the modification/settings screen for the tiling layout via meta+t, I’ve tried playing with the keyboard shortcuts and another user to no avail.
Couldn’t find anything about that issue beyond a reddit post that recommended renaming a configuration file and rebooting but from what was said by others that just breaks the system, haven’t tried that at this stage and won’t be able to until tomorrow as I’ve got work till then.
Beyond that screen is there another way to reset the tiling settings, can’t find anything online.
Win/Meta+Right Arrow is pressed (now the second window takes up all available space instead of just half the screen (this is the undesired behavior, this would previously only result in the window being half the screen resolution ignorant of other windows) Screenshot, 2023-04-08 13:30:09 - Paste.Pics
i have no such issues on my kde with snapping, and im on the testing branch…
and since it doesnt work with the test user either, its something system wide, probably something you installed…
post output from: pacman -Qm
maybe you installed something from aur that causes this…
No clue why deepin wayland got installed, this system to an extent hasn’t been played with so It may have been some bug or mistake on devs part from years ago as I haven’t reset since around 2021 (could still be a mistake on my part though, I’ve been using this machine for development work on hundreds of different projects so perhaps it’s the result of a dep with one of those). Will remove the both of them and see the results once I’m done work (will be tomorrow)
Plasma 5.27 introduced native, better tiling. But it isn’t replacing classic tiling if that is what you want.
Previous tiling was OK, but when you had two screens, the window on the edge of the screen where the next monitor was, didn’t tile, which was highly annoying in infective. Now this problem is gone.
I’m not sure if that what I’m writing is helpful for you, but just in case:
press meta+t - it will show you the default tiling setup, it is pretty intuitive
drag any window and press shift - it will tile the window based on the previous default setup
The old type of tiling still works without shift, but now we had this pretty convenient tiling mode with shift, and it works well with multimonitor setup. For my use cases, it is all I need, but of course for some it may be still not enough.
Cool, thanks for clarifying that it isn’t replacing it, wasn’t 100% sure if the normal window behavior was supposed to act somewhat more like the new tiling functionality or If I was going crazy.
Though it seems in my case the behavior of the classic tiling has changed and is acting like the new tiling which for me is hell, previously tiling was perfect minus being able to see the very edge of the window on the adjacent screen + the whole dialog boxes opening on the wrong screen in such cases.
The exact behavior is better described in a previous post / as below.
I figure to summarize the behavior changes I’m observing now;
With two windows snapped next to each other, re-sizing the x resolution on one window re-sizes the other simultaneously
(in windows a similar behavior is achieved via the toggle “When I resize a snapped window, simultaneously resize any adjacent snapped window”)
Snapping a window and changing it’s size, will permanently affect the snap resolution on the x axis
(Kind of like how you can resize the new tiling window default sizes in the config menu except there’s no config menu involved here)
(Also this sizing change is persistent, changes to it will affect the next window/s to be snapped whether there’s a window currently snapped or not)
After unsnapping a window, it’s resolution from prior to snap is restored
(previously the window would maintain the snapped resolution after being snapped and then dragged away (or at least I believe it did, i distinctly remember snapping my windows often to get an exact half screen size for windows and dragging them around afterwards for precise placement))
This behavior is observed when using meta+ arrow-keys or otherwise moving the window into the edge of the screen
meta+t has no affect on this behavior (tested just in case it was a weird bug with the config menu not being visible or something) (the menu also doesn’t appear for me)
I’ve now rebooted having removed these packages earlier, there was no change in behavior.
I’ve however also noted additional behavior:
After a system reboot, the snap size (affecting x) resets to exactly half the screen however further window size changes after snapping maintains the same behavior as before (affecting adjacent snapped windows and future window snap sizing along the x axis)
A further note,
I’ve renamed ~/.conf/kwinrc to kwinrc_old and then rebooted.
This has resulted in composition enabling on bootup without causing the usual screwy that I would typically encounter upon re-enable, I’m also now able to access the tiling window config overlay.
Playing around with the tiling window manager config screen has no affect on reverting the classic window tiling, same behavior as previously observed.
well unfortunately, i have no idea what to do next, since i dont have these issues, nor other users, otherwise it would be already mentioned, at least in the stable update topic…
i still think it could be something that you installed, but its not installed in foreign packages, but from official repos…
All good, thanks for the help, being that It’s a me issue I won’t be rage quitting kde at least, perhaps in the next kde releases to manjaro stable this will just fix itself otherwise if I discover a fix / someone else has recommendations I’m open to them as I can’t reset/wipe my system for another 8-9 months.
No, previously the tiled window regained previous size when you un-tilled it. The same behavior is now, although I noticed a few times that it didn’t - which is probably a bug.
Yeah, that is correct and planned. It didn’t always work previously, now it does, as far I could notice.
I have never noticed it before, so this is probably a new feature, and I like it. I can unsnapp the windows and snap them again as it was before. I’m not sure if that change is persistent in a new session?
It looks like tiling is a lot more like in Windows now, which is not a bad thing. It seems to be more polished and personalized now. Plus there is this SHIFT tiling, that can be pre-arranged and not dependent on the snapping to edge, which is cool. Just hold the window, click SHIFT and it’s tiled. It can be probably combined with other shortcuts, which makes tiling on KDE more complete. You have mouse tiling and keyboard tiling.
In relation to everything from your post above, thanks for letting me know that this is intentional, it’s at least good to known that someone likes the change at least.
And so now onto my frustrations. What in the literal ■■■■, Every-time something is either perfect or near perfection, modern devs (hell maybe even the old ones idk) decide in the classic google/apple/microshaft fashion, my way or the high way and decide to follow in what is the most stupid trend in tech today and completely change functionality, with little to no warning (can’t find any mention in the change logs beyond the shift+ tiling) and further, give no option for going back to how things were.
I avoid most products/software and write most of my own software because of that and now KDE does this, despite feedback, and they push it into stable, ■■■■■■■■■■■■■
In saying that as well, what is even the point of splitting the two tiling methods for windows (normal drag / meta+arrows **and** the shift+drag method)
They're both virtually the same thing, if you're going to force in a change and overwrite prior functionality, the only thing that adding this shift+drag option did was make this seem like another bug.
Guess it’s onto xfce or something else next.
And back on topic, I’ve found a post in relation to this change
Issue: Re-sizing one snapped window will re-size adjacent
Beyond that though, maybe there is some hope of a fix. Probably not though being that I’ve yet to see any other reply in relation to this issue elsewhere
1.1 “Raising priority as this is rather annoying and we’re getting a lot of negative feedback about it”
1.2 “instead it seems like a bug”