> .. 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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel