hi ... i just pushed a branch in the plasma-mobile repository called aseigo/devicecapabilities. it is a revamping of the org.kde.devicecapabilities engine found in dataengines/devicecapabilities.
changes: * removes the power management related items. those belong in the powermanagement DataEngine in kde-workspace. in fact, i already merged them in kde-workspace master :) * removes the (unimplemented) Input item. * removes the (unimplemented) Screen item. i'm not sure if this is needed in this engine, really. what i could think of as potentially useful is screen resolution, screen enumeration, etc.. but that really sounds like a separate DataEngine to me? * Buttons source: lists special hardware buttons that are available and relevant to applications. the value is a bool noting the buttons existence or not, e.g. "Back" == "false" (or true, if there is one) * Capabilities source: this is for things like "Multitouch" or "Bluetooth" or "Geolocation" or "Telephony" * Sensors source: this is for hardware sensors such as Light (ambient light sensor), Proximity, Accelerometer, Gyroscope, etc. Buttons would be accessable from the DataEngine as well as sources matching the name of the entry in the Buttons source (so one could connect to, e.g. "Home"), allowing easy retrieval of press events. Sensors may also be accessible via this same engine. i haven't quite decided yet whether it would make more sense to have a separate engine for that or not. i currently lean towards the idea that the devicecapabilities engine should, for simple convenience, provide access to the sensor data upon request as well. Capabilities, however, would not be accessed via this engine. they could only be discovered. access to these capabilities would be done through other, purpose-built, DataEngines. this way it is easy for an app to see if telephony is available and if so request the dialer service. in turn, this makes it easier to manage the security of those capabilities and keeps this engine focused and simple. a strategy for customizing the values published by this engine so they match the device is still missing. i would like to avoid having a million patches floating about :) options that i can see include: * different files implementing the init() and similar methods that are device specific and have the "right" device-specific version compiled in a runtime. this seems rather hackish and Bad for maintenance purposes * look for ways to detect at runtime what is available. my concern is that since these things are rather non-standardized that the code would end up with tons of hacks that may or may not work reliably while attempting to figure out e.g. if there is a "Back" hardware button or an accelerometer * have device description files that are read in on start by the DataEngine so that only these files need to be updated / changed and the engine only needs to detect which kind of device it is on. this is something of a hybrid between the above two options i'm not particularly happy with any of the above, and in part my inability to come to something i like is probably due to my lack of familiarity with doing this kind of device integration in the first place :) commens, suggestions, vetos to the revamp, etc all welcome. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
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
