DC setting api

Anton Lundin glance at acc.umu.se
Thu Dec 18 14:59:25 PST 2014


On 18 December, 2014 - John Van Ostrand wrote:

> On Thu, Dec 18, 2014 at 11:50 AM, Anton Lundin <glance at acc.umu.se> wrote:
> >
> > On 18 December, 2014 - john at 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	+46702-161604


More information about the devel mailing list