Bug 167852

this is not a plasma issue so much as a limitation of the NETWM ExtendedStruts being completely useless in a multimonitor situation.

Googling "ExtendedStruts" returns 3 hits, one of which is a Plasma TechBase article that no longer exists.  So it's all Greek to me.

That being said, from the user perspective, somehow windows manage to appear above the plasma panel when it's on the bottom (even on the second window) without overlap.

try stacking the monitors vertically and putting the panel on the bottom of the to p one ;)

it's due to issues with handling edges that are on physical screens but not the whole workspace (so, edges "in between" monitors)

this isn't something we can fix in Plasma, so i'm going to pass it over to the kwin team so they can decide if they wish to work on improving support for these configurations or not.

As of r927455 this also applies to window maximization.

*** Bug 191137 has been marked as a duplicate of this bug. ***

*** Bug 194092 has been marked as a duplicate of this bug. ***

*** Bug 194615 has been marked as a duplicate of this bug. ***

>this isn't something we can fix in Plasma, so i'm going to pass it over to
>the kwin team so they can decide if they wish to work on improving support
>for these configurations or not.

I suppose you wan't to say, that this is not a bug in plasma. If so, then please explain why the panel is displayed in edge of scren where both screens are joined, and not at the end of second screen.
I must tell you are inconsistent in your statement. 
You must decide which way go on to solve this problem. There are 2 ways:
1. Panles must be shown on edges of entire workspace (then windows will be maximized correctly anyway), but management of panels must be changed. In such case bottom or top panel (for case on picture in error report) will be stretched over both screens, and this will be painfull, and could be considered as error from xinerama point of view.
2. Panels will be managed as they are, so the panel can stay on screen edge but somewhere in middle of workspace, but window management must be changed to get correct window maximization.

(In reply to comment #9)
> 2. Panels will be managed as they are, so the panel can stay on screen edge but
> somewhere in middle of workspace, but window management must be changed to get
> correct window maximization.

As i understand, this is what Aaron meant.

Sorry, I didn't read carefully, and ... you can see. :(

*** Bug 192569 has been marked as a duplicate of this bug. ***

*** Bug 198612 has been marked as a duplicate of this bug. ***

*** Bug 182625 has been marked as a duplicate of this bug. ***

*** Bug 199257 has been marked as a duplicate of this bug. ***

*** Bug 206575 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> this isn't something we can fix in Plasma, so i'm going to pass it over to the
> kwin team so they can decide if they wish to work on improving support for
> these configurations or not.

I would like to add my voice to the request for this issue to be addressed if possible.  I'm very grateful for any time that anyone in the kwin team can devote to it.  Thanks.

*** Bug 217131 has been marked as a duplicate of this bug. ***

*** Bug 226075 has been marked as a duplicate of this bug. ***

*** Bug 237938 has been marked as a duplicate of this bug. ***

FYI, a similar bug exists in Gnome too : https://bugzilla.gnome.org/show_bug.cgi?id=339692

Probably the same root cause.

Hope this helps.

@Olivier: yes, see comment #2

(In reply to comment #22)
> @Olivier: yes, see comment #2

I'm afraid I don't understand exactly what you mean in referring to that comment #2... anyway, I noticed http://aseigo.blogspot.com/2008/03/multiscreen-x.html which seems to discuss this issue indeed.

Regards,

The same problem appears in a top/bottom configuration where the task panel is attached to the top of monitor 1. In this configuration the task panel covers vital areas of the window e.G. Close button and the whole menu which makes this configuration completely unusable. Please compare to the attached screenshot of the area 'between the top and the bottom monitor.
 ______________
|              |
|  Monitor 2   |
|              |
|##############|

|##############|
|  Taskpanel   |
|              |
|              |
|___ Monitor 1_|

Created attachment 51319 [details]
task panel covers vital windows areas

windows go under taskpanel in a top/bottom monitor configuration and cover the wm buttens as well as the menue. The task panel is placed at the top of the bottom monitor.

I'm also experiencing this issue with a multi-head setup and would love to see some progress on this.

I'm able to manually circumvent the issue by using snap-to resizing and window state saving the jimmy things into the right position but it would be nice to see a real fix.

Sabayon 5.4 64-bit
KDE 4.5.2

This is also a problem for me, although I use a slightly different dual-screen setup, but the principle is the same:

             ___________
            |           |
            |     2     |
    ________|           |
   |########|___________|
   |   1    |
   |________|

Maximized windows stay behind the top panel in monitor 1 although that panel is set to always visible.

I also hope that one day it will be solved. And that it will not be in KDE 5.3

*** Bug 274597 has been marked as a duplicate of this bug. ***

I hope to see this fixed too. Thanks to anyone addressing this.

this is a really annoying bug/thing. :-)

*** Bug 284581 has been marked as a duplicate of this bug. ***

Can't find the "vote" link, but I'm also suffering from this bug and would be glad if someone could tackle it.

voting wouldn't help either - this is more like an issue with the fdo.org spec, sorry

*** Bug 288091 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 94470 ***

*** Bug 296672 has been marked as a duplicate of this bug. ***

Happening to me too with

[--------------------------------------]
[                                      ]
[           Monitor 1             ]
[                                      ]
[       PANEL                    ]
[--------------------------------------]
[                                      ]
[          Monitor 2               ]
[                                      ]
[--------------------------------------]

windows in monitor 1 do not maximize vertically in the correct way. They extend to the full screen vertical estate, rather than saving the panel vertical space. As a result, the bottom part of maximized windows remain covered by the panel.

(In reply to comment #34)
> voting wouldn't help either - this is more like an issue with the fdo.org
> spec, sorry

Now, does anyone know how to go from here? Who to contact?

Am 26.03.2012 08:51, schrieb hannes:
> https://bugs.kde.org/show_bug.cgi?id=167852
>
> --- Comment #39 from hannes <hannes@michalek.de> ---
> (In reply to comment #34)
>> voting wouldn't help either - this is more like an issue with the 
>> fdo.org
>> spec, sorry
>
> Now, does anyone know how to go from here? Who to contact?
Probably nobody. I doubt there is any interest in extending this part 
of the spec anymore as it is a corner case not valid for other Desktop 
Shells like GNOME Shell or Unity which both don't offer movable panels.

That sucks.

If a spec is obviously wrong and no one has interest in fixing it, the obvious conclusion is that no one cares about the spec altogether. If this is the case, breaking the spec should not be a big issue.

This is an opensource project and the spec is obviously broken and not satisfactory, at least in this specific case. KDE needs not to break the spec but we can. I don't have what is needed to dwelve the code and fix the issue, but maybe any of you can.

It would help if any developer could point us in the right direction to fix and produce a patch.

> If a spec is obviously wrong
The spec is NOT wrong. It is a corner case which had not been 
considered. I cannot tell you whether this has been intentionally not 
been considered or the spec is just too old to consider multiple screens
> and no one has interest in fixing it
I don't see anything to "fix" here. It needs a new extension to support 
this corner case. What I wrote is that I think that nobody has any 
interest in extending the spec to support this corner case as the corner 
case became KDE specific. Which does not justify to have it in a spec.
> the obvious conclusion is that no one cares about the spec 
> altogether.
This conclusion is obviously wrong. Only the corner case is not of 
interest to those not having the corner case
> If this is the case, breaking the spec should not be a big issue.
it has nothing to do with "breaking the spec", the spec needs to be 
extended.

Even better, then.  Initially, I thought that the FD specification explicitly ruled a behavior that is obviously wrong in case of panels placed across screens (hence my wrong conclusion).  Now I guess that it merely does not consider this case.
If this is the situation, it is just a matter to make a sane choice for a behavior that is not ruled at all by the specs. This happens all the time in all fields. Probably there is no need to wait for the body that provides the spec (freedesktop) to provide an extended specification.

(In reply to comment #44)
> What I wrote is that I think that nobody has any 
> interest in extending the spec to support this corner case as the corner 
> case became KDE specific. Which does not justify to have it in a spec.

Does that mean that we may regard it a KDE bug, now? Which would be great as we know KDE *does* fix bugs.

> It would help if any developer could point us in the right direction
> to fix and produce a patch.
I could point you to the locations (as I investigated this once and 
decided it cannot be fixed without an extension to the spec):
* needs support in Plasma to set a different strut
* needs support in KWin to understand the specified strut
* may need changes in area of KDElibs (which would imply no fix before 
KWin and Plasma depend on KF5)

Overall I think it's too much a corner case to be considered for 
implementing. I would rather like to see support for this in KWin's rule 
framework or scripting.

> (In reply to comment #44)
>> What I wrote is that I think that nobody has any
>> interest in extending the spec to support this corner case as the 
>> corner
>> case became KDE specific. Which does not justify to have it in a 
>> spec.
>
> Does that mean that we may regard it a KDE bug, now? Which would be
> great as we
> know KDE *does* fix bugs.
 From a technical point of view I do not see any bug here. It is a 
corner case not considered and not supported by the specification used 
to set struts on panels. That KDE implements/uses a spec is clearly not 
a bug. That the spec does not consider the corner case is clearly not a 
bug. So overall there is no bug.

What would be needed is a change in current existing and intended 
behavior. This means it would be implementing a feature and not a bug 
fix. Given that it has of course to be evaluated whether the corner case 
is important enough to have a special treatment which does no longer 
comply to the used spec.

KDE3 could gracefully cope with the subject, so for me it's a huge step backwards in usability and therefore is a bug, not a feature. Its .8 release in KDE4 branch and this isn't resolved, yet. Windows also has no problems in such configurations, in all versions.

Multi-monitor configurations are not uncommon, anymore, thus there is a benefit of supporting it. Furthermore, I guess, supporting generic of 'Work Area Constraints' can be beneficial  for additional activities.

Dear developers, what's the effort of implementing this... well... feature (let's call it so)?

While from a technical point of view it may appear as a corner case, from an application point of view, it is not.  You may run into this whenever doing presentations and doing presentations is not a corner case.  

It is enough to have a tiled screen mode (clone is not useful for presentation, since you typically want an independent presentation screen to hide your personal stuff from the audience). Whenever you arrange a tiled setup with a bottom panel and presentation screen (VGA1) below the laptop screen (LVDS1) you run into the issue.  Note that it is not very nice to have the presentation screen above the laptop screen because in this case when you fire up the projector screen all your windows go there...  Also note that in many cases you cannot have the main screen and the projector screen tiled horizontally because many graphics card (intel) do not support a sufficient virtual screen horizontal extension.

> KDE3 could gracefully cope with the subject, so for me it's a huge step
> backwards in usability and therefore is a bug, not a feature. Its .8 release
> in KDE4 branch and this isn't resolved, yet. Windows also has no problems
> in such configurations, in all versions.
the best way to make sure that at least I will never implement this feature, 
is to annoy me. Good ways to annoy me, include:
* mentioning that it worked in KDE 3 - seriously nobody cares
* mentioning that it is already the ".n" release of something and STILL not 
fixed - nobody cares. Even if it means that the feature is not needed or the 
users who really need it would have started to hire a company to implement it
* mentioning that Windows supports it. Great then use Windows, I don't care.

I mentioned in comment #47 to this report that I took the time to investigate 
the issue. I had opened both places in Plasma and KWin to add the support, I 
re-read the spec to it. I had completely understood the issue, the code and 
was willing to fix it, which normally at that point means five minutes of more 
work. But there is no fix. Now you can think for yourself whether it's trivial 
or not.

Now this whining in this report has to end or at least I will no longer look 
at it. I don't use a panel between shared edges and as long as I'm not payed 
to fix this issue (if it is fixable at all) whining will not motivate to fix 
something I don't use and which I won't need.

I'm sorry and had absolutely no intention to offend, nor annoy you. I'm new to KDE development but I'll start looking at it. If you can point to good points to start, please, advise.

Again, didn't want to bug you with that.

You can find the relevant code inside plasma in:
kde-workspace/plasma/desktop/shell/panelview.cpp in method PanelView::updateStruts()

It uses an API defined in KWindowSystems which is currently in hard feature freeze for KDE Frameworks 5 (KF5). Due to the moving target of KF5, I'm not pointing to that code. Be aware that no change to kdelibs 4.x can be done any more. Any change which would require adjustment of this API is no longer possible for kdelibs 4.x.

In KWin you find the relevant code in kde-workspace/kwin/geometry.cpp in method Workspace::updateClientArea(bool)

If I remember my investigation correctly this method would already support the case if Plasma would set the strut.

I still think that a better solution would be to use KWin's rule framework or scripting, though that is nothing I have investigated yet, so I cannot give any pointers.

Thanks a lot!

Created attachment 69951 [details]
quick patch to kwin/geometry.cpp

First off all, this:
> KDE3 could gracefully cope with the subject
is complete bull... nonsense.
It did and does work for multiscreen setups and kicker was just *crap* (yes: *crap* - it's even documented all over kwin comments) regarding xinerama support (no idea whether xrandr was even ever supported at KDE3 times)

Attached is a patch for geometry.cpp which mostly fixes whitespaces (drove me complete nuts) and also "prepares" kwin for "correct" multiscreen strutting by -more or less deviating from the NETWM spec- interpreting struts related to the strutting window's screen instead of the desktop.

It works fine with my private desktop shell, but it does NOT work with plasma-desktop, because in screen panels simply don't set struts.

The relevant change is to *move* positions instead of setting them (usually resulting in negative strut rects)

@Martin:
the patch is more or less a hack on what's there, eg this 
    // HACK: workarea handling is not xinerama aware, so if this strut
    // reserves place at a xinerama edge that's inside the virtual screen,
    // ignore the strut for workspace setting.
    if (area == Kephal::ScreenUtils::desktopGeometry()) {
is ridiculous - ::adjustedClientArea() is only used in geometry.cpp - in case plasma-desktop / panel containments ever gets this kind of strutting, please ask back for proper patch

I have managed to get a workaround. I set up a tint2 panel (http://code.google.com/p/tint2/) where I had my old planel. Now the my windows no longer overlap the panel.

If you do not want to use the tint2 panel, you can set up an empty/small tint2 panel and set it to be below your panel.

*** Bug 312906 has been marked as a duplicate of this bug. ***

(In reply to comment #56)
> I have managed to get a workaround. I set up a tint2 panel
> (http://code.google.com/p/tint2/) where I had my old planel. Now the my
> windows no longer overlap the panel.
> 
> If you do not want to use the tint2 panel, you can set up an empty/small
> tint2 panel and set it to be below your panel.

Cheers for the tip, I recently set up panel on the inner edge of a multiscreen desktop, blissfully unaware of the long history of this issue. Putting a completely transparent tint2 panel below the plasma panel and the Strut Policy "follow_size" corrects the overlap. 

Could anyone please explain (to a complete layperson in the area of WMs) why the overlap is not at all an issue for this non-plasma panel?

(In reply to comment #58)

> Could anyone please explain (to a complete layperson in the area of WMs) why
> the overlap is not at all an issue for this non-plasma panel?

Wild guess: your extra panel creates a panel on a horizontal screen edge with the entire screen height (like a bottom panel that would cover the entire sceren, but is only eg 64px wide)

This is some sort of hack. Some WMs might not allow you to move the window at all or not on the other screen or similar weird things.

The entire case was simply not specified by the NETWM.
If one wanted to deviate from it in the mentioned way, that would also require the panels (like in this case plasma-desktop) to deviate in a similar way and set a strut against an inner screen edge (what violates teh specifications would break on other WMs which would add an invisible strut on the outer edge of the combined screen region)

Thanks for the response. I browsed the tint2 code a bit; this is the strut update function: http://code.google.com/p/tint2/source/browse/trunk/src/panel.c#330, and it appears you guessed right. My monitors are 16:9 + 5:4, with the bottom edges aligned, and my panel is at the top edge of the 16:9 monitor. So, in my case the strut extends into the unused virtual desktop area above it. I guess this is the most benign use case, but I see how it is a hack.

*** Bug 319840 has been marked as a duplicate of this bug. ***

*** Bug 310246 has been marked as a duplicate of this bug. ***

*** Bug 323079 has been marked as a duplicate of this bug. ***

*** Bug 324709 has been marked as a duplicate of this bug. ***

*** Bug 355944 has been marked as a duplicate of this bug. ***

Thanks for the workaround hint with tint.
In order to spare others some time, here's a more detailed instruction:

apt-get install tint2
(for Debian based systems)

A minimal config for a transparent panel:
panel_monitor = 2
panel_position = center left vertical
panel_size = 100% 65
panel_layer = bottom

This can easily be adapted. E.g. this config places the panel on the left side of the second screen, 65 pixels wide. That's where I have the KDE panel which shouldn't cover maximized windows.

I saved this config to .tint2rc. Running tint2 now adds the defined panel to the screen. If a maximized window is open, it will immediately resize. Other then that, the panel is invisible.

Since I often change physical workplace, having the secondary display sometimes at the left, sometimes at the right side, I don't always want this fix. Thus I wrote a small script which lets me toggle the panel with a single command:
#!/bin/bash

# if already running, kill it
if kill `pidof tint2`; then
        echo "tint2 killed"
else
        # else start it
        (tint2 -c ~/.tint2rc > /dev/null &) &
        echo "tint2 started"
fi

This is saved to ~/bin/fixdualhead and made executable.
Now I just need to press ALT+F2 and type fixdualhead -> Enter to add or remove the panel.

Git commit 58db4777966e380aede6c2f00b744ef792a49351 by Martin Gräßlin.
Committed on 10/06/2016 at 10:36.
Pushed by graesslin into branch 'master'.

Fix the strut handling for wayland clients

Summary:
The implementation was broken as it transformed the QRects into QRegions,
subtracted the geometries and took the bounding rect again. In several
setups this could result in the strut getting ignored.

This change improves the calculation of the struts by creating a QMargin
which describes the area which needs to be subtracted from a screen rect.
The QMargin is only adjusted for the edge the window borders. We can
assume that a window with a strut needs to border a screen on Wayland.

With this change we are also able to support panels between screens.
On Wayland a panel placed on the right of a left screen affects the
maximization area of the left screen, but does not affect the overall
workarea.

Reviewers: #plasma_on_wayland, #kwin

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D1803

M  +122  -0    autotests/wayland/struts_test.cpp
M  +30   -5    geometry.cpp

http://commits.kde.org/kwin/58db4777966e380aede6c2f00b744ef792a49351