> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
