On 18 December, 2014 - john@vanostrand.com wrote:
Is there any existing work done on an API for presenting and changing settings to applications?
I implemented support for changing settings in OSTC, OSTC3 and Suunto Vyper family devices in Subsurface.
The api that libdivecomputer provides for doing this is really low level, and you need to do quite a bit of work on the application side.
In subsurface we doesn't really abstract things into something common for all devices, because the settings and capabilities of the devices have such wide differences so it doesn't really make sense. Eg. you need a separate UI for each device to accurately represent its capabilities.
//Anton
On Thu, Dec 18, 2014 at 11:50 AM, Anton Lundin glance@acc.umu.se wrote:
On 18 December, 2014 - john@vanostrand.com wrote:
Is there any existing work done on an API for presenting and changing
settings
to applications?
I implemented support for changing settings in OSTC, OSTC3 and Suunto Vyper family devices in Subsurface.
The api that libdivecomputer provides for doing this is really low level, and you need to do quite a bit of work on the application side.
In subsurface we doesn't really abstract things into something common for all devices, because the settings and capabilities of the devices have such wide differences so it doesn't really make sense. Eg. you need a separate UI for each device to accurately represent its capabilities.
I'm working on the configuration of Cochran computers and it has 44 configurable parameters, not including text fields for owner information.
I can see why a custom UI interface has its advantages but I don't see why it can't be generalized to fit all devices.
What I was thinking of was a structure for each setting that defines the setting. It would include a field label, data type, edit parameters (a range, value list, or size restriction), a description (for help), a grouping (for tabs), a dependency specification. Some of the tricky bits could be function calls, like edit, or dependency.
With that kind of structure can't a UI be built on the fly to handle input?
-- John Van Ostrand At large on sabbatical
On 18 December, 2014 - John Van Ostrand wrote:
On Thu, Dec 18, 2014 at 11:50 AM, Anton Lundin glance@acc.umu.se wrote:
On 18 December, 2014 - john@vanostrand.com wrote:
Is there any existing work done on an API for presenting and changing
settings
to applications?
I implemented support for changing settings in OSTC, OSTC3 and Suunto Vyper family devices in Subsurface.
The api that libdivecomputer provides for doing this is really low level, and you need to do quite a bit of work on the application side.
In subsurface we doesn't really abstract things into something common for all devices, because the settings and capabilities of the devices have such wide differences so it doesn't really make sense. Eg. you need a separate UI for each device to accurately represent its capabilities.
I'm working on the configuration of Cochran computers and it has 44 configurable parameters, not including text fields for owner information.
The OSTC have a bit north of 90 configurable parameters =)
I can see why a custom UI interface has its advantages but I don't see why it can't be generalized to fit all devices.
What I was thinking of was a structure for each setting that defines the setting. It would include a field label, data type, edit parameters (a range, value list, or size restriction), a description (for help), a grouping (for tabs), a dependency specification. Some of the tricky bits could be function calls, like edit, or dependency.
Thats a garganthic task to build such a system. Yes, the most common bits and expressions would be doable, but all the crazy things out there, its going to be lots of work.
With that kind of structure can't a UI be built on the fly to handle input?
Of course its possible, but how much work is such a ui building system? I think its multiple times more labor intensive than just building them one by one, for now.
But that said, I would love if you proved me wrong and showed me a resonable path on how we can build such a thing =)
Back to to the original question, i would say take a look at the ostc3 api, thats probably the nicest one to model from.
//Anton
-
Anton Lundin -
John Van Ostrand -
john＠vanostrand.com