Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Martin Gräßlin

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/
---

Review request for kwin and Plasma.


Repository: kde-workspace


Description
---

Screenedge show support for Clients

This provides a new protocol intended to be used by auto-hiding panels
to make use of the centralized screen edges. To use it a Client can
send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
KWin will hide the Client (hide because unmap or minimize would break
it) and create an Edge. If that Edge gets triggered the Client is shown
again. If the Client doesn't border a screen edge the Client gets shown
immediately so that we never end in a situation that we cannot unhide
the auto-hidden panel again. The exact process is described in the
documentation of ScreenEdges.

If KWin gets restarted the Client gets shown again.

As this is a KWin specific extension we need to discuss what it means
for Clients using this feature with other WMs: it does nothing. As
the Client gets hidden by KWin and not by the Client, it just doesn't
get hidden if the WM doesn't provide the feature. In case of an
auto-hiding panel this seems like a good solution given that we don't
want to hide it if we cannot unhide it. Of course there's the option
for the Client to provide that feature itself and if that's wanted we
would need to announce the feature in the _NET_SUPPORTED atom. At the
moment that doesn't sound like being needed as Plasma doesn't want to
provide an own implementation.

The implementation comes with a small test application showing how
the feature is intended to be used.


Diffs
-

  kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
  kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
  kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
  kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
  kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
  kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
  kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
  kwin/tests/screenedgeshowtest.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/115910/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Marco Martin

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50370
---

Ship it!


on plasma side, a +1 ;)

- Marco Martin


On Feb. 20, 2014, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 1:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Thomas Lübking

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---



kwin/screenedge.cpp


what happens if two clients reserve overlapping geometry?
One will be fired, the edge hidden, the cursor enters the edge of the other 
one and that fires as well?
Should the ranged be made exclusive (ie. the overlapping area is given half 
to the one and half the other client?)



kwin/screenedge.cpp


no offese, but this is used once (right below)
Is there actually a point in the lambda that i don't see ore is it "lambdas 
are awesome"?
:-P



kwin/screenedge.cpp


sure?
assume an argb docker with a shadow - the client could visually align to a 
particular screen but the shadow would bleed into the other screen.
evil?

also the docker could be in the center of a huge screen (n panels with 
small bezel)
evil?



kwin/screenedge.cpp


i think this is "wrong".

you're trying to detect the orientation of the panel, but the client likely 
*knows* the orientation of the panel (and where to activate it) - eg. old 
kicker (bottom panel) could collapse horizontally.

imo the client should tell kwin where to (preferably) add the border 
(through the client message)

internal heuristics could only serve as failsafe for lazy clients.



kwin/screenedge.cpp


code duplication with the lambda slot in the constructor?
;-)


- Thomas Lübking


On Feb. 20, 2014, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 1:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Martin Gräßlin


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > 
> >
> > what happens if two clients reserve overlapping geometry?
> > One will be fired, the edge hidden, the cursor enters the edge of the 
> > other one and that fires as well?
> > Should the ranged be made exclusive (ie. the overlapping area is given 
> > half to the one and half the other client?)

I haven't tested it with multiple clients but I do hope that I got it correct: 
they should all fire. Also normal actions should fire. That's in fact something 
i tried, like do the corners still activate if there's also the window.


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1010
> > 
> >
> > no offese, but this is used once (right below)
> > Is there actually a point in the lambda that i don't see ore is it 
> > "lambdas are awesome"?
> > :-P

part of a and part of b ;-) I had the implementation a little bit different 
first and it was used twice. It sticked around, but it could also be a method I 
agree.


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1015
> > 
> >
> > sure?
> > assume an argb docker with a shadow - the client could visually align 
> > to a particular screen but the shadow would bleed into the other screen.
> > evil?
> > 
> > also the docker could be in the center of a huge screen (n panels with 
> > small bezel)
> > evil?

both cases are not valid for the usecase of Plasma. Shadow is done through KWin 
(and thus doesn't matter) and panels can only be on one screen. "evil" in this 
case just means "complicates things". I can change it, but well it complicates 
things as the screenedges are designed to be per screen.


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1032
> > 
> >
> > i think this is "wrong".
> > 
> > you're trying to detect the orientation of the panel, but the client 
> > likely *knows* the orientation of the panel (and where to activate it) - 
> > eg. old kicker (bottom panel) could collapse horizontally.
> > 
> > imo the client should tell kwin where to (preferably) add the border 
> > (through the client message)
> > 
> > internal heuristics could only serve as failsafe for lazy clients.

ah yes the client message, that could work. Client message got added after that 
code part got written, so it didn't occur to me ;-)


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1097
> > 
> >
> > code duplication with the lambda slot in the constructor?
> > ;-)

yes of course I copied it there ;-)


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 20, 2014, 2:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 2:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to an

Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Thomas Lübking


> On Feb. 20, 2014, 4:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1032
> > 
> >
> > i think this is "wrong".
> > 
> > you're trying to detect the orientation of the panel, but the client 
> > likely *knows* the orientation of the panel (and where to activate it) - 
> > eg. old kicker (bottom panel) could collapse horizontally.
> > 
> > imo the client should tell kwin where to (preferably) add the border 
> > (through the client message)
> > 
> > internal heuristics could only serve as failsafe for lazy clients.
> 
> Martin Gräßlin wrote:
> ah yes the client message, that could work. Client message got added 
> after that code part got written, so it didn't occur to me ;-)

I wonder whether the client message should rather be replaced by a property?
It would cover the "kwin restarted" situation as well as be more robust against 
races (plasma starts before kwin) and also export the condition to other 
clients.


> On Feb. 20, 2014, 4:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1097
> > 
> >
> > code duplication with the lambda slot in the constructor?
> > ;-)
> 
> Martin Gräßlin wrote:
> yes of course I copied it there ;-)

Well, what i meant was a common member slot could eventually make sense =)


> On Feb. 20, 2014, 4:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1015
> > 
> >
> > sure?
> > assume an argb docker with a shadow - the client could visually align 
> > to a particular screen but the shadow would bleed into the other screen.
> > evil?
> > 
> > also the docker could be in the center of a huge screen (n panels with 
> > small bezel)
> > evil?
> 
> Martin Gräßlin wrote:
> both cases are not valid for the usecase of Plasma. Shadow is done 
> through KWin (and thus doesn't matter) and panels can only be on one screen. 
> "evil" in this case just means "complicates things". I can change it, but 
> well it complicates things as the screenedges are designed to be per screen.

Let's say a "legal" use of this implies a plain border (no matter along how 
many screens), ie. to have a trigger on the bottom edge, two screens would have 
to align on the bottom edge - thus one edge would be sufficient.

The only complication would be to check whether the window touches the 
requested edge on every screen.

This does not cover a docker bleeding into some dead area, but it's probably 
just to claim that a client bug anyway.

As for the "shadow" case, maybe one could "abuse" _NET_FRAME_EXTENTS (client 
dock setting it) for that matter.
CSD propagaters might have to do sth. in this regard anyway (if you eg. check 
CSD browsers, their _NET_FRAME_EXTENTS is 0 and several things like keeping the 
(unknown and non existent) decoration in sight don't work.


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 20, 2014, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 1:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPOR

Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Martin Gräßlin


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1032
> > 
> >
> > i think this is "wrong".
> > 
> > you're trying to detect the orientation of the panel, but the client 
> > likely *knows* the orientation of the panel (and where to activate it) - 
> > eg. old kicker (bottom panel) could collapse horizontally.
> > 
> > imo the client should tell kwin where to (preferably) add the border 
> > (through the client message)
> > 
> > internal heuristics could only serve as failsafe for lazy clients.
> 
> Martin Gräßlin wrote:
> ah yes the client message, that could work. Client message got added 
> after that code part got written, so it didn't occur to me ;-)
> 
> Thomas Lübking wrote:
> I wonder whether the client message should rather be replaced by a 
> property?
> It would cover the "kwin restarted" situation as well as be more robust 
> against races (plasma starts before kwin) and also export the condition to 
> other clients.

I first tried with a property, but the problem is that there is no way for the 
client to propagate that it should get hidden. So in the end I had property and 
the client message in addition resulting in the property being ignored all the 
time. Thus I removed it again.

The KWin restarted situation is in my opinion quite well handled by having the 
client being shown again. And it's a corner case, our users shouldn't restart 
KWin ;-)


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1097
> > 
> >
> > code duplication with the lambda slot in the constructor?
> > ;-)
> 
> Martin Gräßlin wrote:
> yes of course I copied it there ;-)
> 
> Thomas Lübking wrote:
> Well, what i meant was a common member slot could eventually make sense =)

yes I got that :-)


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 20, 2014, 2:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 2:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Thomas Lübking


> On Feb. 20, 2014, 4:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 1032
> > 
> >
> > i think this is "wrong".
> > 
> > you're trying to detect the orientation of the panel, but the client 
> > likely *knows* the orientation of the panel (and where to activate it) - 
> > eg. old kicker (bottom panel) could collapse horizontally.
> > 
> > imo the client should tell kwin where to (preferably) add the border 
> > (through the client message)
> > 
> > internal heuristics could only serve as failsafe for lazy clients.
> 
> Martin Gräßlin wrote:
> ah yes the client message, that could work. Client message got added 
> after that code part got written, so it didn't occur to me ;-)
> 
> Thomas Lübking wrote:
> I wonder whether the client message should rather be replaced by a 
> property?
> It would cover the "kwin restarted" situation as well as be more robust 
> against races (plasma starts before kwin) and also export the condition to 
> other clients.
> 
> Martin Gräßlin wrote:
> I first tried with a property, but the problem is that there is no way 
> for the client to propagate that it should get hidden. So in the end I had 
> property and the client message in addition resulting in the property being 
> ignored all the time. Thus I removed it again.
> 
> The KWin restarted situation is in my opinion quite well handled by 
> having the client being shown again. And it's a corner case, our users 
> shouldn't restart KWin ;-)

The client could set the property when it wants to be hidden (and also hint on 
which edge to add the trigger)
When showing it, kwin would withdraw the property and withdrawing the property 
could be used by the client to indicate "show me again" (because the user 
turned it into a permanent panel or whatever)


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 20, 2014, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 1:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Martin Gräßlin


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > 
> >
> > what happens if two clients reserve overlapping geometry?
> > One will be fired, the edge hidden, the cursor enters the edge of the 
> > other one and that fires as well?
> > Should the ranged be made exclusive (ie. the overlapping area is given 
> > half to the one and half the other client?)
> 
> Martin Gräßlin wrote:
> I haven't tested it with multiple clients but I do hope that I got it 
> correct: they should all fire. Also normal actions should fire. That's in 
> fact something i tried, like do the corners still activate if there's also 
> the window.

just tested, works as intended: it fires for all clients and actions


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 20, 2014, 2:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 20, 2014, 2:51 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> send a client message of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again. If the Client doesn't border a screen edge the Client gets shown
> immediately so that we never end in a situation that we cannot unhide
> the auto-hidden panel again. The exact process is described in the
> documentation of ScreenEdges.
> 
> If KWin gets restarted the Client gets shown again.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-20 Thread Martin Gräßlin

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/
---

(Updated Feb. 21, 2014, 8:21 a.m.)


Review request for kwin and Plasma.


Changes
---

Adjusted to the suggested changes. It's now based on property instead of client 
messages, which means:
* survives KWin restart
* supports self restoring from Client (see adjusted test app)
* uses a protocol to specify the edge


Repository: kde-workspace


Description (updated)
---

Screenedge show support for Clients

This provides a new protocol intended to be used by auto-hiding panels
to make use of the centralized screen edges. To use it a Client can
set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
As value it takes:
* 0: top edge
* 1: right edge
* 2: bottom edge
* 3: left edge

KWin will hide the Client (hide because unmap or minimize would break
it) and create an Edge. If that Edge gets triggered the Client is shown
again and the property gets deleted. If the Client doesn't border the
specified screen edge the Client gets shown immediately so that we
never end in a situation that we cannot unhide the auto-hidden panel
again. The exact process is described in the documentation of
ScreenEdges. The Client can request to be shown again by deleting the
property.

If KWin gets restarted the state is read from the property and it is
tried to create the edge as described.

As this is a KWin specific extension we need to discuss what it means
for Clients using this feature with other WMs: it does nothing. As
the Client gets hidden by KWin and not by the Client, it just doesn't
get hidden if the WM doesn't provide the feature. In case of an
auto-hiding panel this seems like a good solution given that we don't
want to hide it if we cannot unhide it. Of course there's the option
for the Client to provide that feature itself and if that's wanted we
would need to announce the feature in the _NET_SUPPORTED atom. At the
moment that doesn't sound like being needed as Plasma doesn't want to
provide an own implementation.

The implementation comes with a small test application showing how
the feature is intended to be used.


Diffs (updated)
-

  kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
  kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
  kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
  kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
  kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
  kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
  kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
  kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
  kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
  kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 

Diff: https://git.reviewboard.kde.org/r/115910/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-21 Thread Thomas Lübking


> On Feb. 20, 2014, 4:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > 
> >
> > what happens if two clients reserve overlapping geometry?
> > One will be fired, the edge hidden, the cursor enters the edge of the 
> > other one and that fires as well?
> > Should the ranged be made exclusive (ie. the overlapping area is given 
> > half to the one and half the other client?)
> 
> Martin Gräßlin wrote:
> I haven't tested it with multiple clients but I do hope that I got it 
> correct: they should all fire. Also normal actions should fire. That's in 
> fact something i tried, like do the corners still activate if there's also 
> the window.
> 
> Martin Gräßlin wrote:
> just tested, works as intended: it fires for all clients and actions

Well "intended" sounds race prone.

Assume the client hides the dock as soon as the mouse leaves it.
If you enter the trigger, it will show window #1, then window #2 what will hide 
window #1 and create a trigger for it, what will (since the mouse is still 
there) hide window #2 and create a trigger and also show window #1, the cursor 
leaves window #1 to the trigger of window #2 ... you probably got it ;-)

This might require a mouseMoved flag, a protocol restriction or disjunct 
triggers?


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 21, 2014, 7:21 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 21, 2014, 7:21 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted the state is read from the property and it is
> tried to create the edge as described.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-21 Thread Martin Gräßlin


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > 
> >
> > what happens if two clients reserve overlapping geometry?
> > One will be fired, the edge hidden, the cursor enters the edge of the 
> > other one and that fires as well?
> > Should the ranged be made exclusive (ie. the overlapping area is given 
> > half to the one and half the other client?)
> 
> Martin Gräßlin wrote:
> I haven't tested it with multiple clients but I do hope that I got it 
> correct: they should all fire. Also normal actions should fire. That's in 
> fact something i tried, like do the corners still activate if there's also 
> the window.
> 
> Martin Gräßlin wrote:
> just tested, works as intended: it fires for all clients and actions
> 
> Thomas Lübking wrote:
> Well "intended" sounds race prone.
> 
> Assume the client hides the dock as soon as the mouse leaves it.
> If you enter the trigger, it will show window #1, then window #2 what 
> will hide window #1 and create a trigger for it, what will (since the mouse 
> is still there) hide window #2 and create a trigger and also show window #1, 
> the cursor leaves window #1 to the trigger of window #2 ... you probably got 
> it ;-)
> 
> This might require a mouseMoved flag, a protocol restriction or disjunct 
> triggers?

ok, that's a case I hadn't consider. Suggestion:
1. client gets edge as wanted and stays like that
2. client gets not intersecting parts which can mean no edge at all

Basically: first come, first serve.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 21, 2014, 8:21 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 21, 2014, 8:21 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted the state is read from the property and it is
> tried to create the edge as described.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-21 Thread Thomas Lübking


> On Feb. 20, 2014, 4:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > 
> >
> > what happens if two clients reserve overlapping geometry?
> > One will be fired, the edge hidden, the cursor enters the edge of the 
> > other one and that fires as well?
> > Should the ranged be made exclusive (ie. the overlapping area is given 
> > half to the one and half the other client?)
> 
> Martin Gräßlin wrote:
> I haven't tested it with multiple clients but I do hope that I got it 
> correct: they should all fire. Also normal actions should fire. That's in 
> fact something i tried, like do the corners still activate if there's also 
> the window.
> 
> Martin Gräßlin wrote:
> just tested, works as intended: it fires for all clients and actions
> 
> Thomas Lübking wrote:
> Well "intended" sounds race prone.
> 
> Assume the client hides the dock as soon as the mouse leaves it.
> If you enter the trigger, it will show window #1, then window #2 what 
> will hide window #1 and create a trigger for it, what will (since the mouse 
> is still there) hide window #2 and create a trigger and also show window #1, 
> the cursor leaves window #1 to the trigger of window #2 ... you probably got 
> it ;-)
> 
> This might require a mouseMoved flag, a protocol restriction or disjunct 
> triggers?
> 
> Martin Gräßlin wrote:
> ok, that's a case I hadn't consider. Suggestion:
> 1. client gets edge as wanted and stays like that
> 2. client gets not intersecting parts which can mean no edge at all
> 
> Basically: first come, first serve.

Ultimately, the user should be able to trigger each panel in a deterministic, 
reproducible and understandable way.
A central edge server is in the position to manage the various demands, but if 
we deny adding a trigger (region occluded), clients might fall back to 
something utterly stupid like bringing their own trigger - defeating the 
intention of this approach.
So i do not think, that (2) can be an acceptable solution - we /have/ to 
resolve clashes.

Afaics, there're only two ways of resolution - space and time.

space)
If there's concurrent demand on space, the space could be fairly distributed, 
ie. if two dockers want the entire lower edge, one gets the left and the other 
the right half.
A major issue with this approach is that the (hinted?!) trigger length does not 
match the docker and the separation of our example could be random - depending 
on how the clients are started.
A minor issue is that it will likely be pretty complex to implement ("fair" 
space distribution and geometry management - the presence of triggers will by 
dynamic and that must not impact the layout order)

time)
As a more elegant (and hopefully simple) alternative, i envision sequential 
activation, ie. you trigger panel by panel by repeatingly touching the edge.
It might be sufficient to enforce a global dead-time of 150-250ms and react 
only on (incoming) crossing (not enter) events - eventually we might also want 
to push back the pointer to eg. qMin(50%, 32pt)
Since this would cause the user to perform rather wide cursor movements (try 
bouncing your screen edge several times) and this can cause immediate hiding of 
the panel (actually anything can cause that), we'd explicitly stack a new 
trigger below all others.

-> ?


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 21, 2014, 7:21 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 21, 2014, 7:21 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted

Re: Review Request 115910: Screenedge show support for Clients

2014-02-22 Thread Martin Gräßlin


> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > 
> >
> > what happens if two clients reserve overlapping geometry?
> > One will be fired, the edge hidden, the cursor enters the edge of the 
> > other one and that fires as well?
> > Should the ranged be made exclusive (ie. the overlapping area is given 
> > half to the one and half the other client?)
> 
> Martin Gräßlin wrote:
> I haven't tested it with multiple clients but I do hope that I got it 
> correct: they should all fire. Also normal actions should fire. That's in 
> fact something i tried, like do the corners still activate if there's also 
> the window.
> 
> Martin Gräßlin wrote:
> just tested, works as intended: it fires for all clients and actions
> 
> Thomas Lübking wrote:
> Well "intended" sounds race prone.
> 
> Assume the client hides the dock as soon as the mouse leaves it.
> If you enter the trigger, it will show window #1, then window #2 what 
> will hide window #1 and create a trigger for it, what will (since the mouse 
> is still there) hide window #2 and create a trigger and also show window #1, 
> the cursor leaves window #1 to the trigger of window #2 ... you probably got 
> it ;-)
> 
> This might require a mouseMoved flag, a protocol restriction or disjunct 
> triggers?
> 
> Martin Gräßlin wrote:
> ok, that's a case I hadn't consider. Suggestion:
> 1. client gets edge as wanted and stays like that
> 2. client gets not intersecting parts which can mean no edge at all
> 
> Basically: first come, first serve.
> 
> Thomas Lübking wrote:
> Ultimately, the user should be able to trigger each panel in a 
> deterministic, reproducible and understandable way.
> A central edge server is in the position to manage the various demands, 
> but if we deny adding a trigger (region occluded), clients might fall back to 
> something utterly stupid like bringing their own trigger - defeating the 
> intention of this approach.
> So i do not think, that (2) can be an acceptable solution - we /have/ to 
> resolve clashes.
> 
> Afaics, there're only two ways of resolution - space and time.
> 
> space)
> If there's concurrent demand on space, the space could be fairly 
> distributed, ie. if two dockers want the entire lower edge, one gets the left 
> and the other the right half.
> A major issue with this approach is that the (hinted?!) trigger length 
> does not match the docker and the separation of our example could be random - 
> depending on how the clients are started.
> A minor issue is that it will likely be pretty complex to implement 
> ("fair" space distribution and geometry management - the presence of triggers 
> will by dynamic and that must not impact the layout order)
> 
> time)
> As a more elegant (and hopefully simple) alternative, i envision 
> sequential activation, ie. you trigger panel by panel by repeatingly touching 
> the edge.
> It might be sufficient to enforce a global dead-time of 150-250ms and 
> react only on (incoming) crossing (not enter) events - eventually we might 
> also want to push back the pointer to eg. qMin(50%, 32pt)
> Since this would cause the user to perform rather wide cursor movements 
> (try bouncing your screen edge several times) and this can cause immediate 
> hiding of the panel (actually anything can cause that), we'd explicitly stack 
> a new trigger below all others.
> 
> -> ?

I agree on the space part - that's something I don't want as I think it's not 
very intuitive for the user.

For time: if we only allow to activate one Client per edge at one time it 
resolves the problem by itself: the first trigger will unhide one client and 
remove the edge. So the next trigger will hide the next client.

It probably needs a little bit of playing with a better cursor push back, but 
in general that should work and not be too annoying. After all it's kind of a 
user configuration problem if the user uses multiple auto-hidden clients on the 
same edge ;-)


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50385
---


On Feb. 21, 2014, 8:21 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 21, 2014, 8:21 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of th

Re: Review Request 115910: Screenedge show support for Clients

2014-02-24 Thread Martin Gräßlin

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/
---

(Updated Feb. 24, 2014, 11:16 a.m.)


Review request for kwin and Plasma.


Changes
---

Ensured that multiple clients do not trigger at the same time at an edge. This 
is achieved by updating the trigger time and trigger pos for each edge with a 
Client once we have found an edge which triggers for a Client. Thus the next 
check on time and/or position will just fail and we have the normal 
reactivation treshhold for the edge.


Repository: kde-workspace


Description
---

Screenedge show support for Clients

This provides a new protocol intended to be used by auto-hiding panels
to make use of the centralized screen edges. To use it a Client can
set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
As value it takes:
* 0: top edge
* 1: right edge
* 2: bottom edge
* 3: left edge

KWin will hide the Client (hide because unmap or minimize would break
it) and create an Edge. If that Edge gets triggered the Client is shown
again and the property gets deleted. If the Client doesn't border the
specified screen edge the Client gets shown immediately so that we
never end in a situation that we cannot unhide the auto-hidden panel
again. The exact process is described in the documentation of
ScreenEdges. The Client can request to be shown again by deleting the
property.

If KWin gets restarted the state is read from the property and it is
tried to create the edge as described.

As this is a KWin specific extension we need to discuss what it means
for Clients using this feature with other WMs: it does nothing. As
the Client gets hidden by KWin and not by the Client, it just doesn't
get hidden if the WM doesn't provide the feature. In case of an
auto-hiding panel this seems like a good solution given that we don't
want to hide it if we cannot unhide it. Of course there's the option
for the Client to provide that feature itself and if that's wanted we
would need to announce the feature in the _NET_SUPPORTED atom. At the
moment that doesn't sound like being needed as Plasma doesn't want to
provide an own implementation.

The implementation comes with a small test application showing how
the feature is intended to be used.


Diffs (updated)
-

  kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
  kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
  kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
  kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
  kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
  kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
  kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
  kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
  kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
  kwin/tests/screenedgeshowtest.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/115910/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-26 Thread Martin Gräßlin

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50907
---


@Thomas: any further comments on the latest approach?

- Martin Gräßlin


On Feb. 24, 2014, 11:16 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 24, 2014, 11:16 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted the state is read from the property and it is
> tried to create the edge as described.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-26 Thread Thomas Lübking

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50919
---

Ship it!


See comment. But should be nice for a wild test =)


kwin/screenedge.cpp


ElectricBorderPushbackPixels is by default "1" (and not configurable by UI)
Not sure if this is enough in this context as it's meant to read "i really 
want to go here" (notice that the re/activation thresholds can be arbitrarily 
low)

The user will likely still be moving the mouse when this happens and 1px 
can be crossed by even accidental judder.

Sth. to test (in the wild) but I assume we'll need either special pushback 
distance or reactivation delay.


- Thomas Lübking


On Feb. 24, 2014, 10:16 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 24, 2014, 10:16 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted the state is read from the property and it is
> tried to create the edge as described.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-26 Thread Martin Gräßlin


> On Feb. 26, 2014, 12:18 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 179
> > 
> >
> > ElectricBorderPushbackPixels is by default "1" (and not configurable by 
> > UI)
> > Not sure if this is enough in this context as it's meant to read "i 
> > really want to go here" (notice that the re/activation thresholds can be 
> > arbitrarily low)
> > 
> > The user will likely still be moving the mouse when this happens and 
> > 1px can be crossed by even accidental judder.
> > 
> > Sth. to test (in the wild) but I assume we'll need either special 
> > pushback distance or reactivation delay.

yeah, that is something to test with and also to play with it. With my 
trackball it was OK. Though I'm not sure whether the cursor push back mattered 
or whether the reset of the activation timestamp did the trick. Somehow I think 
the latter - it clearly also protects against accidental judder.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50919
---


On Feb. 24, 2014, 11:16 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 24, 2014, 11:16 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted the state is read from the property and it is
> tried to create the edge as described.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-26 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/#review50924
---


This review has been submitted with commit 
74e98695445ad8f9cb11762e7a7dc5105783f20c by Martin Gräßlin to branch master.

- Commit Hook


On Feb. 24, 2014, 10:16 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115910/
> ---
> 
> (Updated Feb. 24, 2014, 10:16 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Screenedge show support for Clients
> 
> This provides a new protocol intended to be used by auto-hiding panels
> to make use of the centralized screen edges. To use it a Client can
> set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
> As value it takes:
> * 0: top edge
> * 1: right edge
> * 2: bottom edge
> * 3: left edge
> 
> KWin will hide the Client (hide because unmap or minimize would break
> it) and create an Edge. If that Edge gets triggered the Client is shown
> again and the property gets deleted. If the Client doesn't border the
> specified screen edge the Client gets shown immediately so that we
> never end in a situation that we cannot unhide the auto-hidden panel
> again. The exact process is described in the documentation of
> ScreenEdges. The Client can request to be shown again by deleting the
> property.
> 
> If KWin gets restarted the state is read from the property and it is
> tried to create the edge as described.
> 
> As this is a KWin specific extension we need to discuss what it means
> for Clients using this feature with other WMs: it does nothing. As
> the Client gets hidden by KWin and not by the Client, it just doesn't
> get hidden if the WM doesn't provide the feature. In case of an
> auto-hiding panel this seems like a good solution given that we don't
> want to hide it if we cannot unhide it. Of course there's the option
> for the Client to provide that feature itself and if that's wanted we
> would need to announce the feature in the _NET_SUPPORTED atom. At the
> moment that doesn't sound like being needed as Plasma doesn't want to
> provide an own implementation.
> 
> The implementation comes with a small test application showing how
> the feature is intended to be used.
> 
> 
> Diffs
> -
> 
>   kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
>   kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
>   kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
>   kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
>   kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
>   kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
>   kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
>   kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
>   kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
>   kwin/tests/screenedgeshowtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 115910: Screenedge show support for Clients

2014-02-26 Thread Martin Gräßlin

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115910/
---

(Updated Feb. 26, 2014, 11:57 a.m.)


Status
--

This change has been marked as submitted.


Review request for kwin and Plasma.


Repository: kde-workspace


Description
---

Screenedge show support for Clients

This provides a new protocol intended to be used by auto-hiding panels
to make use of the centralized screen edges. To use it a Client can
set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
As value it takes:
* 0: top edge
* 1: right edge
* 2: bottom edge
* 3: left edge

KWin will hide the Client (hide because unmap or minimize would break
it) and create an Edge. If that Edge gets triggered the Client is shown
again and the property gets deleted. If the Client doesn't border the
specified screen edge the Client gets shown immediately so that we
never end in a situation that we cannot unhide the auto-hidden panel
again. The exact process is described in the documentation of
ScreenEdges. The Client can request to be shown again by deleting the
property.

If KWin gets restarted the state is read from the property and it is
tried to create the edge as described.

As this is a KWin specific extension we need to discuss what it means
for Clients using this feature with other WMs: it does nothing. As
the Client gets hidden by KWin and not by the Client, it just doesn't
get hidden if the WM doesn't provide the feature. In case of an
auto-hiding panel this seems like a good solution given that we don't
want to hide it if we cannot unhide it. Of course there's the option
for the Client to provide that feature itself and if that's wanted we
would need to announce the feature in the _NET_SUPPORTED atom. At the
moment that doesn't sound like being needed as Plasma doesn't want to
provide an own implementation.

The implementation comes with a small test application showing how
the feature is intended to be used.


Diffs
-

  kwin/atoms.h 1690067c5d1da59f38f9e77ef64eacfbc1faa0cf 
  kwin/atoms.cpp 904f5efe4a32e3673dae9e6da92bf4336def660d 
  kwin/client.h 6a0dbe4f45f9bb6c58de8c045488cec990e95118 
  kwin/client.cpp 36431bfc33418a207de12fa8cc95a35539256366 
  kwin/events.cpp 1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18 
  kwin/manage.cpp 3e385cd6aeceee3c3bff4e09be2aee130856201f 
  kwin/screenedge.h 60f5fd669ccc5eb627feffa460552558d1765b31 
  kwin/screenedge.cpp 04cf0d6d5262ab84d88559b6dc85e099efec77bf 
  kwin/tests/CMakeLists.txt 3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14 
  kwin/tests/screenedgeshowtest.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/115910/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel