Bug 167852 - Panels on shared screen edges not included in strut area
Summary: Panels on shared screen edges not included in strut area
Status: RESOLVED DUPLICATE of bug 94470
Alias: None
Product: kwin
Classification: Plasma
Component: xinerama (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: LO normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 191137 192569 194092 194615 198612 199257 206575 217131 226075 237938 274597 284581 288091 296672 310246 319840 323079 324709 355944 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-07-31 16:18 UTC by Jeff Mitchell
Modified: 2016-06-10 10:36 UTC (History)
34 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
task panel covers vital windows areas (127.02 KB, image/png)
2010-09-04 20:42 UTC, Thomas Meixner
Details
quick patch to kwin/geometry.cpp (6.53 KB, patch)
2012-03-27 22:02 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Mitchell 2008-07-31 16:18:37 UTC
Version:            (using Devel)
Installed from:    Compiled sources
OS:                Linux

I have a TwinView setup with the primary monitor on the left.  Yesterday I moved the Plasma panel to the left side of the secondary monitor (I have no idea if the dual-monitor setup is relevant, so I'm including it anyways):

[------------][------------]
|            ||P           |
|     1      ||P     2     |            
|            ||P           |
[------------][------------]

Now, whenever new windows appear on monitor 2 (i.e. if that is where my mouse cursor is), they always appear on the left side of the screen against the left edge, i.e. behind the Plama panel, making me drag each window to the right as they appear.
Comment 1 Aaron J. Seigo 2008-07-31 21:21:54 UTC
this is not a plasma issue so much as a limitation of the NETWM ExtendedStruts being completely useless in a multimonitor situation.
Comment 2 Jeff Mitchell 2008-07-31 22:04:49 UTC
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.
Comment 3 Aaron J. Seigo 2008-08-01 20:23:37 UTC
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)
Comment 4 Aaron J. Seigo 2008-12-11 02:32:30 UTC
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.
Comment 5 lucas 2009-02-17 17:03:15 UTC
As of r927455 this also applies to window maximization.
Comment 6 Martin Flöser 2009-04-30 14:19:04 UTC
*** Bug 191137 has been marked as a duplicate of this bug. ***
Comment 7 Martin Flöser 2009-05-30 09:45:05 UTC
*** Bug 194092 has been marked as a duplicate of this bug. ***
Comment 8 Martin Flöser 2009-05-30 09:45:18 UTC
*** Bug 194615 has been marked as a duplicate of this bug. ***
Comment 9 Mirek Mieszczak 2009-05-31 10:32:44 UTC
>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.
Comment 10 Kishore 2009-05-31 20:07:45 UTC
(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.
Comment 11 Mirek Mieszczak 2009-05-31 22:04:14 UTC
Sorry, I didn't read carefully, and ... you can see. :(
Comment 12 Martin Flöser 2009-06-10 09:25:49 UTC
*** Bug 192569 has been marked as a duplicate of this bug. ***
Comment 13 Martin Flöser 2009-07-02 10:35:51 UTC
*** Bug 198612 has been marked as a duplicate of this bug. ***
Comment 14 Martin Flöser 2009-07-02 10:36:38 UTC
*** Bug 182625 has been marked as a duplicate of this bug. ***
Comment 15 lucas 2009-07-08 04:08:16 UTC
*** Bug 199257 has been marked as a duplicate of this bug. ***
Comment 16 Martin Flöser 2009-10-21 14:41:26 UTC
*** Bug 206575 has been marked as a duplicate of this bug. ***
Comment 17 Tony Lewis 2009-11-05 16:54:43 UTC
(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.
Comment 18 lucas 2009-12-03 02:26:56 UTC
*** Bug 217131 has been marked as a duplicate of this bug. ***
Comment 19 Martin Flöser 2010-02-09 23:20:35 UTC
*** Bug 226075 has been marked as a duplicate of this bug. ***
Comment 20 Martin Flöser 2010-05-17 17:40:46 UTC
*** Bug 237938 has been marked as a duplicate of this bug. ***
Comment 21 Olivier Berger 2010-06-24 10:54:12 UTC
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.
Comment 22 Aaron J. Seigo 2010-06-24 16:14:02 UTC
@Olivier: yes, see comment #2
Comment 23 Olivier Berger 2010-06-24 16:22:03 UTC
(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,
Comment 24 Thomas Meixner 2010-09-04 20:38:21 UTC
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_|
Comment 25 Thomas Meixner 2010-09-04 20:42:05 UTC
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.
Comment 26 Adam Jorgensen 2010-10-25 09:06:23 UTC
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
Comment 27 Ricardo Graça 2010-11-21 15:26:38 UTC
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.
Comment 28 Marcin Juszkiewicz 2010-12-20 18:02:04 UTC
I also hope that one day it will be solved. And that it will not be in KDE 5.3
Comment 29 Martin Flöser 2011-05-31 17:29:44 UTC
*** Bug 274597 has been marked as a duplicate of this bug. ***
Comment 30 Leonardo 2011-06-02 02:26:38 UTC
I hope to see this fixed too. Thanks to anyone addressing this.
Comment 31 Panagiotis Papadopoulos 2011-07-03 21:22:53 UTC
this is a really annoying bug/thing. :-)
Comment 32 Martin Flöser 2011-10-21 04:26:54 UTC
*** Bug 284581 has been marked as a duplicate of this bug. ***
Comment 33 hannes 2011-11-08 08:21:21 UTC
Can't find the "vote" link, but I'm also suffering from this bug and would be glad if someone could tackle it.
Comment 34 Thomas Lübking 2011-11-13 16:43:26 UTC
voting wouldn't help either - this is more like an issue with the fdo.org spec, sorry
Comment 35 Thomas Lübking 2011-12-02 22:56:04 UTC
*** Bug 288091 has been marked as a duplicate of this bug. ***
Comment 36 Thomas Lübking 2012-03-07 00:04:55 UTC

*** This bug has been marked as a duplicate of bug 94470 ***
Comment 37 Martin Flöser 2012-03-24 09:32:29 UTC
*** Bug 296672 has been marked as a duplicate of this bug. ***
Comment 38 Sergio 2012-03-24 16:27:58 UTC
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.
Comment 39 hannes 2012-03-26 06:51:00 UTC
(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?
Comment 40 Martin Flöser 2012-03-26 07:17:26 UTC
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.
Comment 41 Adam Jorgensen 2012-03-26 07:31:57 UTC
That sucks.
Comment 42 Sergio 2012-03-26 10:46:39 UTC
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.
Comment 43 Leonardo 2012-03-26 13:07:51 UTC
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.
Comment 44 Martin Flöser 2012-03-26 13:32:25 UTC
> 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.
Comment 45 Sergio 2012-03-26 13:53:54 UTC
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.
Comment 46 hannes 2012-03-26 13:56:22 UTC
(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.
Comment 47 Martin Flöser 2012-03-26 14:00:49 UTC
> 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.
Comment 48 Martin Flöser 2012-03-26 14:17:55 UTC
> (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.
Comment 49 Pavel Gurevich 2012-03-26 15:21:18 UTC
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)?
Comment 50 Sergio 2012-03-26 15:43:26 UTC
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.
Comment 51 Martin Flöser 2012-03-26 16:25:04 UTC
> 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.
Comment 52 Pavel Gurevich 2012-03-26 17:49:56 UTC
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.
Comment 53 Martin Flöser 2012-03-26 18:05:26 UTC
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.
Comment 54 Pavel Gurevich 2012-03-26 18:12:45 UTC
Thanks a lot!
Comment 55 Thomas Lübking 2012-03-27 22:02:00 UTC
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
Comment 56 priomsrb 2012-09-10 02:19:39 UTC
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.
Comment 57 Thomas Lübking 2013-01-08 20:44:04 UTC
*** Bug 312906 has been marked as a duplicate of this bug. ***
Comment 58 Steven Franzen 2013-03-12 16:11:24 UTC
(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?
Comment 59 Thomas Lübking 2013-03-12 16:38:01 UTC
(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)
Comment 60 Steven Franzen 2013-03-13 15:01:53 UTC
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.
Comment 61 Martin Flöser 2013-06-06 11:50:28 UTC
*** Bug 319840 has been marked as a duplicate of this bug. ***
Comment 62 Martin Flöser 2013-06-07 13:23:18 UTC
*** Bug 310246 has been marked as a duplicate of this bug. ***
Comment 63 Thomas Lübking 2013-08-01 16:38:10 UTC
*** Bug 323079 has been marked as a duplicate of this bug. ***
Comment 64 Thomas Lübking 2013-09-09 17:39:32 UTC
*** Bug 324709 has been marked as a duplicate of this bug. ***
Comment 65 Martin Flöser 2015-11-26 13:54:28 UTC
*** Bug 355944 has been marked as a duplicate of this bug. ***
Comment 66 didi156 2016-03-01 16:46:23 UTC
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.
Comment 67 Martin Flöser 2016-06-10 10:36:28 UTC
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