Change the encoding of attribut definitions

[MartinGrosshaus]

The attribute definitions currently rely on the length of the entry to encode the requiered length of the attribute, e.g. "ssss" for a string with a length of 4.
It would be easier and clearer, if this definition would look more like "s, 4".
Additionally it would enable the definitions to contain more information like alignment or if this attribute is requiered or could be left empty.

[jamaa]

What about using a standard string formatting convention such as this one? https://docs.python.org/3/library/string.html#format-specification-mini-language

A string of length 4, right-aligned, could be {s:>4}. A float with 2 decimal places could be {f:.2f}. A float with two decimal places, right-aligned to a total string length of 6, could be {f:>6.2f}.

I'm not sure if this would cover all use-cases, though. For example, I'm not sure if you can force a float to be formatted with a specified number of total characters, I think you can only specify the number of decimal places. But maybe the syntax can be used anyway, even if the plugin has to do some extra work for e.g. shortening numbers.

[MartinGrosshaus]

I love conventional standards as much as the next guy - but on the one hand I think we can do it even more efficient and on the other hand the standard string formatting convention (as you suspected) would not cover all of our use-cases :-)

We have decision values ("J/N") and special date/time values like "TT.MM" (only 1 dot), which aren't covered in the convention.
Additionally, we don't need to specify the number of decimal places because the plugin already shortens or elongates a float to the "best" number of characters (all possible information of the source, but within the maximum total number of characters specified).

I have the following suggestion for the definition:

[ 1 character to identify the data type ][ 1 space ][ maximum total number of characters possible ][ 1 space ][ additional info ]

We don't need curly brackets because every definition is set in their own litte cell in the definitions file.
The plugin could read the definition as a string and then split it at the spaces to make a list out of it.

The first item in that list would identify the data type.
i = integer, f = float, s = string, Y = decision value
If the definition is for one of several different date/time values, then the full definition is written down (e.g. "TT.MM hh:mm").

The second item would contain the maximum total number of characters possible.
This information could be left blank for decision and date/time values.

I'm not sure any more, that the alignment of the text should be encoded in the definition, because the default is strings-left and numbers-right. To my knowledge this fits in all cases (only the ALL-file might look nicer with left-aligned numbers).
And the part about "this entry is required" is also a bit shaky.
But that's the beauty of this definition:
If "additional info" is needed one day, it could be easily encoded in a third or fourth item - but it's not needed now.

Examples:
s 4 -> string with 4 characters max
i 6 -> integer with 6 character max
f 10 -> float with 10 characters max
Y -> decision value with the length of 1
hh:mm -> time value with the length of 5

maybe later:
s 10 > X -> a string with a maximum of 10 characters, which will be right-aligned and is extremely important/can not be left blank

[jamaa]

I fully agree 👍