Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 11:14 UTC (Tue) by lgeorget (guest, #99972)
Parent article: Gräßlin: Multi-screen woes in Plasma 5.7

Hi Martin, very instructive blog post, thank you. I have not used Plasma for a long time because I prefer tiling window managers but I believe you when you say that multi-screen is difficult. I remembered that it took me a long time (plus a lot of scripts/systemd units/udev rules) to get the multi-screen to work reasonably.

I have a question, which may sound naive to you, about a point in the article:

> KWin places new windows on the “active screen”. The active screen is the one having the active window or the mouse cursor (depending on configuration setting). Unless, unless the window adds a positioning hint. Unfortunately it looks like windows started to position themselves to incorrect values and I started to think about ignoring these hints in future.

Isn't it possible to validate the positioning hints from any new window, check whether they belong to the valid display area (i.e. inside the virtual display, not on a switched-off monitor, etc.) and ignore them if they are invalid? Wouldn't that solve at least the matlab splash screen and skype notifications issues?

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 11:47 UTC (Tue) by mgraesslin (guest, #78959) [Link] (7 responses)

> Wouldn't that solve at least the matlab splash screen and skype notifications issues?

matlab case yes, skype case no as it's an override redirect window.

The question is whether it's the right thing to do? Maybe there are valid cases to put windows off-screen? The general assumption here is that applications know what they do.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 11:57 UTC (Tue) by micka (subscriber, #38720) [Link] (2 responses)

> The general assumption here is that applications know what they do.

Well, it seems the assumption might be not entirely exact them :)
Of course, if *most* applications do, being defiant towards applications might break more things than it fixes.

I'd really like if firefox stopped trying to place itself. While not really broken, it sometimes does unrational things.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 12:37 UTC (Tue) by mgraesslin (guest, #78959) [Link] (1 responses)

> I'd really like if firefox stopped trying to place itself. While not really broken, it sometimes does unrational things.

On the other hand when clicking session restore in Firefox it places the window to the exact position. So there it does the right thing.

I guess it's like always: if there are two possible ways to handle that, no matter which one we choose we have users unhappy with the situation.

Nevertheless I think we need to evaluate this condition again. We can do better by doing safety tests and we do them in other areas.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 12, 2016 19:44 UTC (Tue) by oever (guest, #987) [Link]

On the other hand when clicking session restore in Firefox it places the window to the exact position. So there it does the right thing.

Only if that position is still visible. The user might have had Firefox on an auxiliary monitor when in dual screen mode and started it again in single screen mode. In that situation, I think KWin already places Firefox in the visible area and ignores the position provided by the application.

I guess ideally, the WM would remember the last position of each application for each monitor setup. So then it would know that I like Firefox on the big monitor when that monitor is attached.

On a side-note, Plasma 5.7 just landed on NixPgks master and it is mostly running fine. I've submitted bug reports for the most annoying remaining issues. I'm happy with Project Neon, because it gives packagers a baseline to compare their packages with. Packagers can now see if something is a bug in packaging or in the software by running the corresponding Project Neon ISO.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 13, 2016 1:31 UTC (Wed) by xtifr (guest, #143) [Link] (3 responses)

> The general assumption here is that applications know what they do.

Scary! :D

Fvwm, for all of its arcane configuration, allowed you to specify on a case-by-case basis whether an app's position requests and other hints should be followed or ignored. This really might be the only viable solution for now: blacklists of programs which can't be trusted.

Of course, adding any sort of user-friendly UI to something like this would be quite difficult. And I suspect there's too many poorly-behaved programs out there to reliably create a predefined list. (Although I suspect it's mainly a problem with older programs.)

FVWM

Posted Jul 13, 2016 8:00 UTC (Wed) by oldtomas (guest, #72579) [Link]

> Fvwm, for all of its arcane configuration, allowed you to specify on a case-by-case basis whether an app's position requests and other hints should be followed or ignored.

And this is, among others, the reason why I returned to Fvwm, after a longish excursion through Gnome and then XFCE: the window manager is on *my* side, while apps not always are. Since software started having "opinions" (and being proud of it) I feel I need one or two sizeable cluesticks to beat it into submission.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 13, 2016 11:31 UTC (Wed) by ovitters (guest, #27950) [Link] (1 responses)

I'm pretty sure KWin has the same functionality in a GUI. IIRC by default it did something for Flash. However, being able to fix an application just for yourself is still working around the problem.

Gräßlin: Multi-screen woes in Plasma 5.7

Posted Jul 13, 2016 15:00 UTC (Wed) by nix (subscriber, #2304) [Link]

It does have the same functionality: it's got a huge list of bug workarounds you can activate on a window-by-window or class-by-class basis (for those few applications that actually *use* window classes any more :( )