org.kde.devicecapabilities

[Aaron J. Seigo]

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
-------------- 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/20110916/b8dafff9/attachment.sig>