[deviceinfo] Add os and firmware information properties. JB#57114 #22
Conversation
src/deviceinfo.h
Outdated
| @@ -48,6 +48,9 @@ class SYSTEMSETTINGS_EXPORT DeviceInfo: public QObject | |||
| Q_PROPERTY(QString designation READ designation CONSTANT) | |||
| Q_PROPERTY(QString manufacturer READ manufacturer CONSTANT) | |||
| Q_PROPERTY(QString prettyName READ prettyName CONSTANT) | |||
| Q_PROPERTY(QString osName READ osName CONSTANT) | |||
| Q_PROPERTY(QString osVersion READ osVersion CONSTANT) | |||
| Q_PROPERTY(QString firmwareVersion READ firmwareVersion CONSTANT) | |||
There was a problem hiding this comment.
Firmware being a bit vague term I'm pondering if we could use something more concrete. In our case this is sort of hw adaptation version. Also to be seen how much we need this exposed, ref: comment on buteo-mtp if it should use osVersion.
There was a problem hiding this comment.
I was struggling with that... usually one tries to keep terminology in sync with ssu, but this is something ssu does not expose. And we have something that is read from "hw-release", QDeviceInfo legacy is "firmwareVersion", and what it actually means is "adaptation version"...
I've been thinking about: use "hw_release" naming in ssu-sysinfo to match source of data (which is what ssu does internally too), and "adaptationVersion" here where we know we are dealing with sailfish context. How does that sound to you?
In any case, I guess it would not hurt to document all of those properties.
There was a problem hiding this comment.
There was a problem hiding this comment.
I've been thinking about: use "hw_release" naming in ssu-sysinfo to match source of data (which is what ssu does internally too), and "adaptationVersion" here where we know we are dealing with sailfish context. How does that sound to you?
Those names sound better to me. Though thinking should we even add this yet here since usage got dropped in buteo etc.
For another thing, this and the os name + version are already also available in AboutSettings.
There was a problem hiding this comment.
Those names sound better to me.
Changed, both here and in ssu-sysinfo.
Though thinking should we even add this yet here since usage got dropped in buteo etc.
There are more packages to patch. And migrating is easier if there is feature parity. Not that I'm sure all of these are that beneficial. But it is easy to drop them once it is known for sure that they are needed - as long as dropping is done before release. Or alternatively, once things stabilize enough, I could stash them in separate feature branch to be added if there is genuine need.
For another thing, this and the os name + version are already also available in AboutSettings.
If the long term goal is to have single source for this info, having c lib, used by a qt/qml wrapper lib + making AboutSettings use that too would seem like a logical choice to me.
There was a problem hiding this comment.
We could add comments here and here:
I was thinking about "developer documentation", so describing what the methods are supposed to do and how they relate to similar functions elsewhere. Having comments in /etc files is probably not helpful towards that goal, or did I misunderstand what you meant?
spiiroin
force-pushed
the
jb57114_os_version
branch
from
67c5e30
to
e13beb0
Compare
|
Review commits squashed |
Allows lightweight access to os / firmare version information without using custom /etc/*-release parsers. Signed-off-by: Simo Piiroinen <simo.piiroinen@jollamobile.com>
spiiroin
force-pushed
the
jb57114_os_version
branch
from
e13beb0
to
9c31ca3
Compare
|
Force pushed |
Allows lightweight access to os / firmare version information without
using custom /etc/*-release parsers.
Signed-off-by: Simo Piiroinen simo.piiroinen@jollamobile.com