Review Request 115910: Screenedge show support for Clients

Sat Feb 22 09:13:09 UTC 2014

> On Feb. 20, 2014, 5:59 p.m., Thomas Lübking wrote:
> > kwin/screenedge.cpp, line 170
> > <https://git.reviewboard.kde.org/r/115910/diff/1/?file=245042#file245042line170>
> >
> >     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 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140222/1dc7f808/attachment.html>