Screen Edge handling in 4.11

[Martin Graesslin]

On Monday 21 January 2013 12:53:21 Aaron J. Seigo wrote:
> 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.
fine with me. It would have got a "subdomain" anyway. freedesktop I imagine 
will be difficult as it doesn't match the design of GNOME Shell/Unity.
> 
> 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.
kded is difficult as KWin is interacting very intensely with the edges and going 
to another process would be bad(tm) for that (e.g. when moving a window with 
switch desktop when moving windows only, the edges get activated when moving 
starts and deactivated on ending)
> 
> 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 #?
very unsure as we need to have a consistent screen numbering and I don't think 
that exists.
> 
> 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
> ..)
Fine with me, no problem adding that.
> 
> (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.
would that work with e.g. KRunner registering the top-center area of each 
screen?

Otherwise I'm fine with that, too. Seems cleaner the way you describe it - I 
had thought about it, but kind of preferred the signal approach. But having a 
similar approach to SNI sounds reasonable to me. Do you have me pointers to:
* code of this in SNI
* SNI spec?

--
Martin Gräßlin