Device capabilities / platform status service

[Aaron J. Seigo]

On Saturday, June 1, 2013 19:27:16 Ivan Čukić wrote:
> Hi all,
> 
> For the shell switching / capabilities-based component loading, we'll need
> to have the system to get the capabilities of UI devices (obviously :) ).
> 
> The service (guessing org.kde.platformstatus will fit this purpose) will
> need to be able to:
>  - get the keyboard, attached/detached events
>  - mouse/touchpad devices, --||--
>  - touch-screen devices (don't think those can be turned on/off on a same
> screen, so we don't really need events for these)
>  - screen resolution

there is already a DataEngine in plasma-mobile called 
org.kde.devicecapabilities, though a generic dbus service would be nicer for 
other applications. the DataEngine will need to be adapted to this service 
however.

.. or it could be a library rather than a service?

screen resolution is already handled by other means. the only use case i can 
actually think for any of the things listed is the keyboard: if there is a 
hardware keyboard, don't show the on-screen software keyboard.

things like GPS, g-sensor, etc would be useful (we have those in the 
DataEngine now .. though it isn't dynamic but rather reads a device config, 
that needs improving obviously). particularly since these things can be 
powered off to save on battery.

if the service could also be used to request that these be turned on, that'd 
be fantastic. some thinking towards security might also be useful in that 
case.

> Also, I have a question regarding the actual implementation of
> org.kde.platformstatus. Do we really need it to be a kded service since it
> needs to be tightly integrated into plasma (and deal with all async stuff),
> or we could just have it as a part of plasma binary, but expose via d-bus
> for other applications?

How does it need to be more tightly integrated into Plasma than it does kwin 
or any other part of the system? The applications running may also want to 
adjust their UI, and I don't see that as more or less important than the 
desktop shell adjusting.

The real issue is that this requires some cooperation from the window manager. 
When there is a change then, from a user's POV:

* the screen should fade to a waiting screen
* the screen should fade back in with everything in its new place

that means that window manager needs to trigger a compositing effect and *then* 
plasma-device and other applications can do their magic .. when they are 
finished (or a timeout is reached?) the window manager can let the desktop be 
visible again.

the fade effect can happen while the changes are happening (the compositor can 
take the last state and then fade to something else, e.g.) so that can be in 
parallel .. but the fade back in needs communication / cooperation from the 
various processes that might need changing around.

note that session management of a sort also comes into play: processes may be 
started and stopped.

so i don't see any advantage of putting this service into the desktop shell 
itself when the window manager needs to orchestrate things. i also don't 
believe the triggering mechanism belongs in the window manager / compositor 
any more than any other system level event does.

-- 
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/20130602/623239bd/attachment.sig>