Documenting the ini file

rbe2012 wrote: Oops, this was not intended... documentation is often boring
But to be honest: I thought about that too. This thread showed again that many (only some?) people edit their config files instead of using a potentially complex user interface to change the values. A documentation should point to the corresponding place in the gui.
Should we open a new thread beyond "How To"?

For me the big advantage of understanding and being able to read the Modelxx.ini files is that one can quickly read through a file provided by someone and understand how the TX is configured and how it will behave - all in one place on one screen.

The alternative would be to connect your tx to the PC, load the ini file and go through each screen trying to remember each detail - not a good use of my time.

The use of the ini-file is indisputable - I use them the same way, but all my configs were created from the gui; just to be sure of their correctness.

Now let's make a real job of it. Where should we start?
I see these steps (all comments in brackets are my opinion):

• search a place to save intermediate and final results (the forum is not because it makes teamwork difficult; I would prefer a new bitbucket repo or something similar)
• define format (should be similar to the regular manual)
• define a structure (easiest: the main blocks "global", radio, mixer, gui-qvga...)
• for every structure element: describe the use of this block, describe the possible parameters, their possible values, the page / place in the gui where it will be set in the real tx / emulator (separate for standard and advanced) and give some (one) example
• write a general description where everything what was announced to be a problem for some users is mentioned: filesystem, editor, line endings, 4k-size, comments in the file, the way the config is read, stored and written, ...
• search for volunteers who will write one section

I have taken the manual file from PBs manual repo, cleared all but saved the formatting. I put a few headlines inside to give you a clue what I think.

I am anxious to see if uploading a fodt-file will work directly...
EDIT: no, did not... zipped now, should run.

100% happy with the approach, will look at the .fodt files tonight and add what I can contribute. A new repo on bitbUcket would be a great way to manage it, we can move it to PB's document repo once done. If you open it I'll push my changes back.

(I can understand why FDR has blocked certain files types - This .fodt file zips down to <20% of normal size)

Ok, I will open a new repo - will see how to set the rights correctly so you can push too (if I don't get it we will work with clones and pull requests as usual).

PB has chosen the fodt format because it is version control system compatible. It is human readable, because it is a large xml-file. So we can expect that zipping will find many equal strings to compress really good.

FDR wrote: Actually I hasn't blocked the .fodt intentionally, it simply was not on the list of allowed extensions by default...

Well is seems with good reason

The only problem I noticed is that the system does not warn a user when it is not loading a file, does Kunena not have an option to alert the user?

RandMental,
I cloned PB's manual repository here: deviation-modelconfig-manual . I gave you write access, but I can not test if it will work.
The file uploaded some posts ago is committed.

I added a file with my additions and a few format suggestions, however I might have messed up your original in the push process. (My mercurial skills is not what it should be)

It has worked somehow - I have seen two commits, but I will look into the files tomorrow.

I have looked at your doc.
We have two different ways to work on the documentation together: we can do it with means of mercurial (that means we work with the same doc and commit the changes and pull / push often) or we can do it without the help of mercurial (we work on different docs and put them together later).
I prefer the last one because we are more independent from each others work. We will only have to make sure that at the end we have a single document. What I mean: the resulting document should look like it is written from a single author, homogeneous and completely rounded.
If you agree we should inform each other which part we will work on next.
At first I will transfer the whole model.c method in the structure. Everything what the method knows will be described so this will give us the complete overview.
I go on working on the doc I created before.

Happy with you proposal that we do add what we can in separate documents for now.

Truth is at this point I don't have to much factual info on the ini file to add. For small additions or suggestions to your doc I shall do a pull request and you decide - we can't have two editors on one doc at the same time .

Hi RBE, pushed a few updates to the manual and tried to remove my original draft document, however it is still in the repository. Could you please delete it, we use you file as the working copy.

Hmmm, a new challenge... I never have deleted a file from a repo...
I think I have to pull, mark the file as to be forgotten and push again... I will try later.

That is what I tried, but perhaps my write access rights dont allow it. Did not get any errors from mercurial though.

RandMental wrote: That is what I tried, but perhaps my write access rights dont allow it. Did not get any errors from mercurial though.

It has nothing to do with write access - the mercurial server is not the place where we do changes to the repo. I can't do that either.
This has to be done in our local copy. The command PB said will do the trick (I did not know this, but it is similar to git).

Someone was faster than me ...again.