Screen Edge handling in 4.11

[Aaron J. Seigo]

On Monday, January 21, 2013 11:03:53 Martin Gräßlin wrote:
> The protocol I would suggest is:
> 1. Application calls D-Bus function in KWin with the following information

imo this should be a new DBus service name (e.g. org.kde.screenedges) with an 
eye of perhaps even getting org.freedesktop.screenedges so that other 
environments / window managers can elect to provide this same service.

kwin could continue to provide it, but i'd like to avoid poking org.kde.kwin 
directly for this service.

the worst part of this is that we'll be breaking hiding panels with any other 
window manager out there. the original idea was to have this in kded (or as a 
separate process, even, if need be) so that it remained independent and have 
window manager, desktop shell and applications use this.

as for applications using this ... i can't imagine many applications wanting 
to rely on kwin for screen edge features.

>  * which edge to monitor (left/right/top/bottom)
>  * offset on edge
>  * length on edge

screen #?

we will also want to be able to update the screen edges being monitored. in 
the case where uinique IDs + signals are used, being able to update an 
existing screen edge request ID would be preferred as otherwise a client 
application needs to send 2 dbus calls (both of which are in theory async ..)

(the same is true of the callback method described below)

> 2. KWin returns a unique identifier for the registered area
> 3. Whenever this area is triggered, KWin emits a dbus signal with the unique
> identifier as parameter

another possibility is to do it as we do the system tray: the application 
("client") registers a dbus callback with the screen edge ("server"). when the 
trigger criterion (screen/edge/offset/length) is met, the server calls all the 
matching callback method. 

this has advantages:

* server can monitor client dbus service to know when it goes away
* instead of emitting a signal to all clients, only the client(s) that should 
be notified will be notified by calling the client callbacks. this allows the 
server to supress the call to some registered clients even if they requested 
that screen edge (use case: panels and full screen windows)
* applications can remove their dbus service to remove the screen edge 
requests, rather than call into the server directly. this also happens to 
cover the "application quit or crashed" scenario.
* no tokens to manage (just client-side service names)

if we want to make it so that one client service can handle mulptiple edges, 
then it gets trickier. but if we assert that each screen edge requires its own 
dbus service for callback, then it is quite trivial:

org.kde.screenedges:
	registerTrigger(int screen, int edge, int offset, int length, string 
clientService, string objectPath)

application side:
	screenEdgeEvent()

calls to registerTrigger with the same clientService+objectPath would update 
the geometry for that trigger, so a special call for that is not necessary. 
the objectPath allows multiple triggers in the same application while keeping 
the application api simple (and avoiding having to send any data over the bus 
from the server to the client)

if we want just one client service, however, to handle all requests for a 
single application it becomes trickier...

given that it is unlikely for any given application to have more than a few 
such triggers (even plasma-desktop with multiple screens is unlikely to have 
more than a handful), the one-dbus-object-per-trigger should not result in 
overhead issues.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130121/c1393f96/attachment.sig>