Device capabilities / platform status service

[Ivan Čukić]

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

Honestly, a library (khm khm solid) would be imo the right target. First, we 
can make it as a separate one, and then merge into solid when we are satisfied 
by it, and when kf5/solid is deemed stable.

> 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.

How so? If we have a touch screen - load active shell and active ui for apps, 
if a normal screen - load desktop (potentially netbook depending on the size 
of the screen), if there is a mouse - show the cursor even on active shell.

> 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.

+1 though at a later stage. If these features go into a library, we could 
expose them to the scripting engine in a secure manner.

> 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 current kded module (platformstatus) deals with plasma shell mainly - that 
part is tightly integrated with plasma - for that I don't see a reason to be 
outside of plasma-shell. I agree that the rest should not be in plasma. 

> 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.

This can be *really* problematic - if we want to wait for all applications to 
finish their changes before fading-in, we'll end up with another session 
protocol (or hacking around the current one which proved to be a impossible 
task to do properly). And a misbehaving application could make the system 
unusable or to seem slow.

I think that applications will mostly have smaller changes to make compared to 
plasma and therefore be faster. If it proves not to be true, we can later do 
the session-like thing, or to make a localised version of the kwin effect to 
apply to the windows that haven't finished changing before plasma.

> 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.

Agreed.


Cheerio,
Ivan

-- 
Progress isn't made by early risers. It's made by lazy men trying to find
easier ways to do something.
  -- Robert Heinlein