Device capabilities / platform status service

[Aaron J. Seigo]

On Sunday, June 2, 2013 10:57:44 Ivan Čukić wrote:
> > 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.

mouse+cursor is a good point. touch screen alone is not enough to know when to 
load a different shell (laptops are now coming with touch screens equipped by 
default)

something else that belongs in the platformstatus kded module which isn't 
there right now are the triggers for automatically switching from one form 
factor to another. this needs to be handled in one place so that the order of 
events that it triggers, which happens across multiple processes, can be 
started in a coordinated fashion.

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

a way to control which dataengines and services a plasmoid has access to will 
be needed. (and QML imports. .. another story)

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

it currently provides access to the platform description, which is not plasma 
shell specific at all, and the shell package (which mostly is). it needs to 
also have the look and feel package for all the other UIs that need to adjust 
as a result. this is because the Look and Feel package may be set up 
differently depending on the shell (as we do right now for desktop v. active) 
and i'd prefer not to have all N components which will be using Look and Feel 
to have to watch for all possible changes in config separately.

this is pending some work that needs to be done on configuring the L&F package.

i have considered putting this in a library which listens to the dbus signal 
for the runtime platform definition and then provide ways to get at the packges 
from a class there.

the benefit of a library is that it would avoid rountrips to fetch the packages 
to use. i'm not sure if that matters very much however, as there would still 
be dbus signal for the runtime platform change. the only saving would be on 
startup.

the downside of a library is that it is one more thing to link to and would 
want to link to libplasma2 making it awkward for non-workspace applications.

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

The alternative is to show the interface while applications may still be 
adjusting and that will simply look unpolished. 

Yes, this will mean a rethink to the session handling somewhat (something new, 
something added to what exists, I don't know). 

This is not important to deal with right now, however. The important thing is 
to realize that the kded module is not in any way specific to the shell.

-- 
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/1c433a41/attachment.sig>