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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
