Devo12 GUI and model*.ini-files

As I have started working on the gui for Devo12 (more toggle icons, bars, boxes on main screen as proposed in another thread) I saw that it is impossible to make such improvements without adding new lines to the model config files.
E.g. for additional boxes we need the line "box#=[soure]" (as we now have for box1-box8) to save these values the same way as now with the models.
This is similar for the other gui objects.
To start I decided to define some constants like NUM_BOXES, NUM_BARS... in the gui/[resolution]/_gui.h file. This way I can associate the gui's size/resolution and the numbers of elements to be shown there.
But to save them needs the above described modifications in the modelXX.ini files. I used box9-box12 as parameter labels. The old CONFIG_ReadModel / ini_handler tests if the value given is >box8 so box9 will be marked as error and box10-box12 will be read as box1.
Again this makes the files in parts incompatible, at least to former versions of deviation.
To resolve this new names must be used (like ext_box1-ext_box4) which can't be mixed up with the regular parameter labels. Thinking further a mapping method could be useful, maybe similar to the use of capabilities.h.

What do you think?

Here some examples:or this:

I think that, as you've introduced the new #define NUM_BOXES then you can change the model.c to something like:


if (idx >= NUM_BOXES) {
printf("%s: Unkown key: %s\n", section, name);
return 1;
}


In me repo I have had a 5th toggle switch icon on the main page of Devo10/7e. To do that I've introduced a new #define NUM_TOGGLES (in target/devoXXX/tagrget_defs.h) and it works well.

(May be I do not understand something about your problem?)

You are right; I can do this (and I have done it this way).
There are two problems with that (the special box case):

1. The ("old") code is not aware of digits > 8 (hard coded) and of numbers consisting of more than one digit. This can be resolved by making some smaller code changes.
2. If we simply count up the numbers the model files will contain lines like "box9=Ch3" or "box12=Timer2". If you try to load such a model file in a deviation version which is not aware of the additional elements (even if it can't use them; e.g. an elder version) you will run into an error, but the file will be loaded (throws some errors in the emulator). You will not only loose some features which will be silently ignored but rather they can't be rewritten to the model file. So if you use the file again in a deviation version which knows about the extensions they are gone and have to be reconfigured.

One way to resolve this would be using a second model*.ini-file which contains everything what is more than that what is in the actual model file. But what about the next modifications? A third file?
Another way would be using an additional file which contains the extensions for all models in one file (sort of database). But it will be not easy to write changes to this file (reading is simple). Maybe we can write changed data always at the end and clean up from time to time...

With your 5th toggle did you encounter problems when exchanging model files? Not every Devo10/7e will make use of this until the code is integrated in PhracturedBlue's main stream. And even then we will have older versions (we can not assume that everyone is willing to make all updates).

As I mentioned somewhere else a sort of versioning of model files could help. But this would have to be designed and integrated as early as possible - and we are shortly before 3.0 so maybe it's too late... But I think I will make some attempts in this direction.

For the new (5th) Toggle icon, older version will simply ignore it...
And I think that it will be the same for your features ?
In fact you just replace an hard coded number (for exemple 8 ) by a
preprocessor instruction (which is strictly the same for the final code)..

First we have to say that model.ini files are parsed in the config/model.c (in the ini_handler() function), nowhere else (I think?) those files are parsed. So, we have only to take care to the code in the ini_handler() config/model.c

Important think is : "What does old code do with a model.ini new parameter ?"
Answer: It does always ignore it.

A ) I think that if the parameter name is completly new, it will always ignore (for exemple: ext_boxN in your case).

B ) Some parameters are composed which 2 parts (a name and a number) and can be eventually recognized by the parser . In this case we have to take care if old code verify well the part number (and ignore the parameter if the part number is too big), if this is the case there is no problem...
and I think that this is the case (but may be I make a mistake somewhere).

[EDIT] : Ok I see some number parameters can be greater than 9 but only one digit is supported in the code Sorry

Domcars0,
the number parameters are one of the problems, but this can be resolved with some easy code modifications.

I will try to explain my problems. Maybe I was not clear enough but as you know I am not a natural English speaker...

We have many ways to add new values: new parameter names, new numbers, modified values (as done with the toggle icons), new sections, new subsections as FDR described, new files, ...
One thing is the same for all of these possibilities: older versions will ignore them or throw an error message (at least in the emulator). And this leads to two conclusions:
1) we always have to take care that the original parts (the least common denominator) will result in a valid configuration
2) if we load and save a config with a version which does not know the new parameters they will be lost

Sooner or later we come to a point where we have to decide how to handle such additional parameters in the ini files. Do we want to preserve backwards compatibility in any case? Should we completely using new formats to make clear that they are version specific?
Personally I think compatibility is a huge important factor. I want deviation to be backwards compatible. A newer version should understand older ini-files and behave like the older version would do with the same file. I really think this is important for updates - otherwise everybody would have to remake all of his model files when updating deviation.
Keeping this in mind (if you agree) we would have to modify the functions concerning reading and writing model files. This should be done once and as soon as possible. From this time on we have a mechanism which is aware of different versions of tx- and model-configs, although we can't see now how much modifications to the model files the future will bring us.

I have made some attempts for the additional boxes in the Devo12-gui. I implemented additional sections which take the new parameters. It would look like this in the modelXX.ini-file:Here are the definitions (in config/model.h):and here a part of the code (in config/model.c, function ini_handler):Writing code looks like this:
You can have a look at my repo ( deviation-rbe;versioning ). Only the emulator for Devo12 makes use of it (make TARGET=emu_devo12 WINDOWS=1 && ./emu_devo12.exe in my case). It is not perfect and not even ready but can serve as a proof of concept.

I have a 12 and an 8. It would be nice to move a model file to the 8 use it (maybe adjusting trims or something) then move it back to the 12 and still have any settings on the 12 still there.

Minor thing that obviously I can live without and wont effect everyone.

But just from a basic file handelling perspective if there are settings in a file its always best to try to preserve them.

FDR wrote: ...is that really that bad? It won't use them anyway...

Hexperience wrote: It would be nice to move a model file to the 8 use it ... then move it back to the 12 and still have any settings on the 12 still there... Minor thing that obviously I can live without and wont effect everyone.

This is the central question: keep it as far as possible (in both directions) or don't care about the rest...
Sounds a little bit emotional, sorry for that, but describes good the issue: in the second case we might lose owners of some tx, the people who does not want to update too often... The interchangeability will be reduced.
It is easy to ignore unknown parameters (it's done yet this way) but maybe hard to preserve these parameters if I want them when I go back to Devo12 again.
As we have read in the forum there are users who have more than one tx, a big heavy nice one for the great flying days and a small one with less features for the little flight here and there.

I would have to agree with FDR. As a JR user for many years the compatibility between model data of a 8 channel TX and a 10/12 channel TX has never been there. I understand the desire for this type of compatibility, but at some point it is bound to create problems and cause the loss of a piece of RC equipment.