KDE's Multi-Monitor Support Continues To Be Improved

[ngraham]

Ok, this made me recheck one old bug: when the panel/taskbar is on the side and on that side there is also a second monitor, auto-hide wouldn't work properly (it would go in loop of hide and show, unable to make up its mind). Now, if I tell it to auto-hide, it won't hide at all. Not sue if that counts as a fix.
Fwiw I checked this on X, I can't check Wayland right now (in the middle of something, I can't afford to have my open windows go MIA again), but I will at some point.

Still not fixed.

Kind of hard to "fix", though. Auto-hide panels only un-hide when you touch the pixel adjacent to their screen edge. This is easy most of the time. But when there's another screen on the other side of that edge, it's almost impossible. I have difficulty thinking of a conceptually sane way to improve this that wouldn't either annoy the hell out of people (e.g. adding some resistance before the cursor can move to the other screen) or involve losing the ability to make panels on those edges be auto-hidden at all.

[ngraham]

I wouldn't say that the multi-monitor has "improved", in fact it's highly broken currently that the primary panel no longer follows the proper primary display, and their new method doesn't handle the whole priority properly. This is annoying as with 4 monitors, it moves my main taskbar to the far 4th display and behaves badly if I move it manually. Plus it's even more confusing now that they still don't show the attached port with the devices in the gui - all my displays are the same, I can't tell them apart!

I have to use the nvidia-settings app or finally just made a small one-liner xrandr script to set my displays since kde can't figure out multi-montior support still after a few decades. I was better off on 5.26...

Please read https://notmart.org/blog/2023/02/how...tiscreen-bugs/ and file a bug report! Your setup is exactly the kind of "wild and wacky arrangement" I was alluding to in the blog post.

FWIW I suspect that a big part of the problem is your use of nvidia-settings and xrandr in conjunction with KScreen. Your system now has three sources of truth for what the screen arrangement should be; it's no wonder it gets confused. I strongly recommend only using KScreen to manage screen arrangement, and then submit bug reports for things that don't work properly.

[Berniyh]

I wouldn't say that the multi-monitor has "improved", in fact it's highly broken currently that the primary panel no longer follows the proper primary display, and their new method doesn't handle the whole priority properly. This is annoying as with 4 monitors, it moves my main taskbar to the far 4th display and behaves badly if I move it manually. Plus it's even more confusing now that they still don't show the attached port with the devices in the gui - all my displays are the same, I can't tell them apart!

I have to use the nvidia-settings app or finally just made a small one-liner xrandr script to set my displays since kde can't figure out multi-montior support still after a few decades. I was better off on 5.26...

Did you try that with a clean config or is this a config that was carried over from some very old plasma version?
If the latter, maybe retry with a clean config, just to be sure that it's not some weird migration issue.

[bug77]

Still not fixed.

Kind of hard to "fix", though. Auto-hide panels only un-hide when you touch the pixel adjacent to their screen edge. This is easy most of the time. But when there's another screen on the other side of that edge, it's almost impossible. I have difficulty thinking of a conceptually sane way to improve this that wouldn't either annoy the hell out of people (e.g. adding some resistance before the cursor can move to the other screen) or involve losing the ability to make panels on those edges be auto-hidden at all.

Would it be feasible to make the "hit" area 5 or 10 pixels wide, instead of just one? And activate if the cursor hovers over there for some time (e.g. 100ms or whatever testing reveals to be a sane value)?

[ngraham]

Would it be feasible to make the "hit" area 5 or 10 pixels wide, instead of just one? And activate if the cursor hovers over there for some time (e.g. 100ms or whatever testing reveals to be a sane value)?

The issue with making the hit area bigger is that the panel could then appear and cover UI elements of a maximized app that are near or touching the screen edge when you try to interact with them. This issue would be especially severe if the panel is on the right edge as it would make it almost impossible to interact with scrollbars. It would be extremely frustrating.

[bug77]

The issue with making the hit area bigger is that the panel could then appear and cover UI elements of a maximized app that are near or touching the screen edge when you try to interact with them. This issue would be especially severe if the panel is on the right edge as it would make it almost impossible to interact with scrollbars. It would be extremely frustrating.

Yeah, exactly how that RDP panel shows up when I try to fiddle with browser tabs.
In that case, can you just disable that option when the panel is not on true desktop edge? Maybe with a tooltip explaining why it's disabled? But still, I would try it with a 3 or 5 pixels wide hit box, see how it goes.

[mikus]

Please read https://notmart.org/blog/2023/02/how...tiscreen-bugs/ and file a bug report! Your setup is exactly the kind of "wild and wacky arrangement" I was alluding to in the blog post.

FWIW I suspect that a big part of the problem is your use of nvidia-settings and xrandr in conjunction with KScreen. Your system now has three sources of truth for what the screen arrangement should be; it's no wonder it gets confused. I strongly recommend only using KScreen to manage screen arrangement, and then submit bug reports for things that don't work properly.

I did on kde bugs (hopefully in the right place), it's been sitting there idle for a week since arch released 5.27. https://bugs.kde.org/show_bug.cgi?id=465889

I don't disagree it's not some carryover artifact, but it needs managed or migrated if so, it's not practical to tell someone to wipe their .config data every time a new feature is introduced. They do need to coexist to some extent, as with the nvidia card, I can't get sddm or any other dm to launch without a configured xorg.conf for the display, and at least can manage creating that.

Also aligning displays in KDE settings is still maddening, particularly with 4 as there is no proper snapping at corners vs doing so in nvidia-settings. It's super easy to get overlap or +/- off between displays as you can't tell when they're properly aligned in any way.

[mikus]

I did on kde bugs (hopefully in the right place), it's been sitting there idle for a week since arch released 5.27. https://bugs.kde.org/show_bug.cgi?id=465889

Funny, I was your first comment post to that article even.

I filed this under kscreen, as it seemed to be odd around the settings side not reflecting the primary from the proper order. The panel misbehaving per your description there might be related as well, but sort of a toss up, one or the other to start with. I posted some visuals and the kscreen-doctor output on links there, if you feel better suited I can reassigning to plasma/multi-screen.

[evasb]

I hope they cut some features from KDE 6, mainly the most problematic ones that don't have a maintainer.

KDE 6 can be a pretty good release.

[bug77]

I hope they cut some features from KDE 6, mainly the most problematic ones that don't have a maintainer.

KDE 6 can be a pretty good release.

Why not remove every feature that's not popular with developers? And while at it, rename the whole project to Knome.