<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/115910/">https://git.reviewboard.kde.org/r/115910/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On February 20th, 2014, 5:59 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/115910/diff/1/?file=245042#file245042line170" style="color: black; font-weight: bold; text-decoration: underline;">kwin/screenedge.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">bool Edge::canActivate(const QPoint &cursorPos, const QDateTime &triggerTime)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">170</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="n">unreserve</span><span class="p">();</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?)</pre>
</blockquote>
<p>On February 20th, 2014, 7:25 p.m. CET, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On February 21st, 2014, 8:19 a.m. CET, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">just tested, works as intended: it fires for all clients and actions</pre>
</blockquote>
<p>On February 21st, 2014, 3:42 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?</pre>
</blockquote>
<p>On February 21st, 2014, 4:37 p.m. CET, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On February 21st, 2014, 7:21 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.
-> ?</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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 ;-)</pre>
<br />
<p>- Martin</p>
<br />
<p>On February 21st, 2014, 8:21 a.m. CET, Martin Gräßlin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for kwin and Plasma.</div>
<div>By Martin Gräßlin.</div>
<p style="color: grey;"><i>Updated Feb. 21, 2014, 8:21 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kde-workspace
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kwin/screenedge.h <span style="color: grey">(60f5fd669ccc5eb627feffa460552558d1765b31)</span></li>
<li>kwin/screenedge.cpp <span style="color: grey">(04cf0d6d5262ab84d88559b6dc85e099efec77bf)</span></li>
<li>kwin/tests/CMakeLists.txt <span style="color: grey">(3fa16f21c617a8f4b39b2bbd39b534b6a11e8d14)</span></li>
<li>kwin/tests/screenedgeshowtest.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>kwin/atoms.h <span style="color: grey">(1690067c5d1da59f38f9e77ef64eacfbc1faa0cf)</span></li>
<li>kwin/atoms.cpp <span style="color: grey">(904f5efe4a32e3673dae9e6da92bf4336def660d)</span></li>
<li>kwin/client.h <span style="color: grey">(6a0dbe4f45f9bb6c58de8c045488cec990e95118)</span></li>
<li>kwin/client.cpp <span style="color: grey">(36431bfc33418a207de12fa8cc95a35539256366)</span></li>
<li>kwin/events.cpp <span style="color: grey">(1fa6e425d4dac7d661612e5d090c3c9c8f4b1a18)</span></li>
<li>kwin/manage.cpp <span style="color: grey">(3e385cd6aeceee3c3bff4e09be2aee130856201f)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/115910/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>