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