Remove readconf.py

[markus2330]

The readconf.py needs an update too, so using that won't work either right now.

What does that mean for the user?

Does LCDproc works with old config files?

[kodebach]

What does that mean for the user?

Nothing really.

Does LCDproc works with old config files?

I will either update readconf.py or create some other automated update procedure that reads the old config files and puts them into the KDB. I don't plan to support them beyond that. A few things won't be supported 100%, but I think we can live with that. (things like taking the name for a menu from the ini section)

One thing that definitely won't be supported for now is passing the path to the config file via the command line. That would obviously not be the Elektra way. I have some ideas on how to support multiple configurations, but I still need to find out what works best. Possibly the best idea is to just rely on the dir namespace.

[markus2330]

I will either update readconf.py or create some other automated update procedure that reads the old config files and puts them into the KDB.

So we are actually not tied to INI. Maybe we can even use YAML (@sanssecours?)

One thing that definitely won't be supported for now is passing the path to the config file via the command line.

The maintainer is relaxed about this anyway, see ElektraInitiative/libelektra#1416

Possibly the best idea is to just rely on the dir namespace.

Yes.

[kodebach]

Maybe we can even use YAML

If the yaml plugins support everything we need. It would certainly make writing the menus easier (assuming Elektra arrays are mapped to yaml arrays).

The maintainer is relaxed about this anyway, see ElektraInitiative/libelektra#1416

It seems not entirely unlikely, that someone is running multiple instances of LCDd on one machine (under different ports). Think of one machine with 2 LCDd instances each setup with a different LCD display and clients connecting to one of the LCDd instances to have them show up on separate LCDs.

But that should be possible to setup with the dir namespace.

[sanssecours]

If the yaml plugins support everything we need.

I think YAML CPP should support most of what you need. I would currently not recommend any of the other YAML plugins.

It would certainly make writing the menus easier (assuming Elektra arrays are mapped to yaml arrays).

Yes, the plugins map YAML sequences to Elektra’s array data type.

[markus2330]

@sanssecours Thank you for your answer! Do you think it is a good idea to start with yamlcpp now and then later migrate to yanlr (or whatever we found to be the best YAML plugin)?

[sanssecours]

Do you think it is a good idea to start with yamlcpp now and then later migrate to yanlr (or whatever we found to be the best YAML plugin)?

Since both of those plugins currently use exactly the same YAML mapping, I think migrating between them should – at least in theory – not be a problem at all.

[markus2330]

@kodebach What is the state of readconf.py?

[kodebach]

What is the state of readconf.py?

Somewhere between semi-broken and broken. I never updated it for the high-level API and even for the low-level API it is not fully correct.

For now the best way is to manually rewrite the configuration for the Elektra version. For setting up lcdexec menus, I created a script which is also installed as lcdexec-setup. The other clients and the server should be straightforward to update.

As for drivers, some might require bigger changes than others. For instance the keymatrix configuration in the hd44780 driver is a bit different to the old version, similarly the linux_input configuration changed a bit.

[markus2330]

Ok, better we remove readconf.py then.