Bug 299247 - Break NETWM to allow inner xinerama struts
Summary: Break NETWM to allow inner xinerama struts
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compatibility (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: 4.11
Assignee: KWin default assignee
URL:
Keywords:
: 345468 352239 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-02 17:33 UTC by Thomas Lübking
Modified: 2016-08-29 06:50 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: Decision-Required+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lübking 2012-05-02 17:33:29 UTC
see bug #167852
It's not to hard to change this, i guess using the window position to determine the affected screen is a usable choice but
a) nevertheless we'd break NETWM
b) plasma currently doesn't support this

So it needs a choice to be taken
Comment 1 Dave 2013-03-10 04:10:37 UTC
Pardon the lay perspective.  I've been following this issue for some time.  I understand that a true fix would be to make the specification more robust.  This issue though, is many years old and solving it would be an immediate productivity boost for many users.  Right now, many of us are stuck without the ability to maximize windows.

It seems there is a philosophical aversion to breaking a specification, which we've already determined is inadequate.  I work in an office with engineers and developers; over 50 machines with multiple monitors.  I don't believe we're unique and I'm certain that multi-headed desktops are not a corner case.

I suspect, from the statement "It's not hard to change this," that a usable workaround would be technically trivial.  It is my opinion that, in this case, pragmatism should take priority over ideology.
Comment 2 Gauss 2013-11-11 18:04:29 UTC
I'm absolutely in favour of breaking the NETWM specs at this point, either as a default setting or optionally by including a nicely sounding checkbox like "Activate KDE NETWM extensions" or similar in the settings.
In my opinion this bug (I really consider this a bug, even if the specs tell otherwise) is one of the biggest usability issues of KDE, at least for multiscreen environments.

Best
Thomas
Comment 3 csabi 2014-04-09 14:38:13 UTC
I totally agree with Thomas.
Comment 4 Thomas Lübking 2014-06-10 10:48:20 UTC
*** Bug 336014 has been marked as a duplicate of this bug. ***
Comment 5 Thomas Lübking 2015-03-24 09:16:47 UTC
*** Bug 345468 has been marked as a duplicate of this bug. ***
Comment 6 Alexander Nestorov 2015-03-24 09:25:48 UTC
I'm affected by this "bug" and I got very pissed when I read that this wasn't fixed because it would mean breaking an already broken specification.

@Thomas you say a choice should be taken. Who must take that choice? Can that person/team's attention be attracted to this bug?
Comment 7 Martin Flöser 2015-03-24 09:28:51 UTC
not sure whether it makes sense on X11 - Wayland will fix it
Comment 8 Alexander Nestorov 2015-03-24 09:34:34 UTC
@Martin What doesn't make sense? Fix a (from what I read, trivial) bug that will  improve usability?
It makes a lot of sense imho.

The way I see it: this bug is caused because kwin follows an obviously broken NETWM rule and the fix is trivial, but it didn't get applied because you don't want to break NETWM.

I understand NETWM exists for a reason, and the specs should be followed. But in this corner case I'd say it would be better to break the specs and improve usability, right?

On the other hand, we all know that Wayland just won't get any time soon*, so fixing this sounds reasonable.


* Not in the next 6-12 months
Comment 9 Thomas Lübking 2015-03-24 09:43:34 UTC
The proposed fix is *not* "trivial", it requires a bilateral agreement between plasmashell and kwin that will make them break other relations in this regard (ie. plasmashell + openbox + multiscreen = epic fail)

Alternatives:
a) Fix NETWM, you may approach wm-spec-list@gnome.org anytime and try your luck.
b) Add a third, proprietary, strut hint to be preferred (plasmashell does not even have to check whether the WM supports it) - would be "kwin + plasma" only as well, but at least not break other combinations

@Martin
Does wayland really provide anything that's not a "kwin deals this with plasma on private relations" solution?
Comment 10 Martin Flöser 2015-03-24 10:01:37 UTC
> Does wayland really provide anything that's not a "kwin deals this with
> plasma on private relations" solution?

yes/no. It will not be part of the "official" Wayland protocols as for all those "we put the shell into the compositor" it doesn't make sense. But in general we want our protocol to be re-usable by more than plasmashell, e.g. I know that LXQt and Hawaii are interested.
Comment 11 Alexander Nestorov 2015-03-24 10:05:51 UTC
So, if I'm understanding correctly, Wayland won't actually fix this. It will be you patching kwin/plasma to talk to each other and agree on the height of the window (in this case).
If I'm not wrongly understanding this (excuse me if I am), I really can't see any difference between that and the "b" option that @Thomas proposed.
Comment 12 Martin Flöser 2015-03-24 10:13:42 UTC
(In reply to Alexander Nestorov from comment #11)
> So, if I'm understanding correctly, Wayland won't actually fix this. It will
> be you patching kwin/plasma to talk to each other and agree on the height of
> the window (in this case).

No, the difference is that we have multi-output from the start. Currently we don't even support panels on Wayland, but when we do, it will work automatically.
Comment 13 Will Price 2015-09-04 20:02:33 UTC
*** Bug 352239 has been marked as a duplicate of this bug. ***
Comment 14 Martin Flöser 2016-08-29 06:50:23 UTC
I think we did the decision: the strut related changes in 5.7 basically broke the NETWM spec and Plasma 5.8 sets the strut on the shared screen edge.