[Lcdproc] Patch to improve generation of edition and validation tool for /etc/LCDd.conf

[Dominique Dumont]

Le Sunday 23 October 2011 20:50:42, Markus Dolze a écrit :
> while working on lcdproc today I thought about your ideas and your
> config editor (which I think is great) and how we can help you.

Great news. Thanks :-)

> I don't like the idea of putting regex code into LCDd.conf as the file
> still is hand-edited by many users. I believe regular expression may
> confuse our users even more.

Fair enough.

> One idea I had was to generate LCDd.conf from another file that could be
> easily parsed by Config::model upon 'make'. But this requires some tool
> that can easily be integrated into the autotools chain without adding
> too 'heavy' external programs / libraries (e.g. Perl or Python). 

Good idea. Generating LCDd.conf from another file will actually be easier 
and more predictable.

In order to minimize the learning curve of people dealing with specifying 
this file (i.e. you and all other lcdproc driver contributors), the format 
of this file should be as close as possible as the original LCDd.conf file.

I'll come back to that at the end of this mail.

> If the patches you sent help you with config editor I'm happy to commit
> them (probably changing the lastline stuff).
> 
> One thing to keep in mind is that "yes", "true", "y", "on" and "1" all
> have the same meaning within LCDd.conf. Instead of "lastline=true" we
> can also write "lastline=yes" or "lastline=on" and all are valid. The
> same accounts for "no", "false", "n", "off" and "0". Your parser should
> account for that, especially if it reads an already existing file.

Indeed. I faced a similar issue with xorg.conf. In Config::Model, the 
boolean type is rather liberal in which value is seen as true or false. 
Internally, the value is stored as 1 or 0 (which is handy to provide a 
check button in a GUI)

The only issue is to decide what to write back in the file. Currently 
0 or 1 are written back. Which may not be ideal. 

> Are the spaces between "#" and the key really required as seen in
> "comments" patch?

Currently yes.

When parsing the file to find the list of paramater, I have to take 
into account:
- uncommented parameters
- commented parameters (with '#' prepended)
- repeated parameters (like Hello and Goodbye)
- documentation (with '# ' prepended)

The menu comments specify several ways to use the *Key parameters. If 
left as is, the parser will think *Key parameters can be repeated in 
the file like "Hello". Which is not true. The space enable the parser to 
consider these keys as doc and not repeatable parameters.

I admit that this solution looks like a hack. Generating LCDd.conf 
from another file will provide another solution.

So, let's go back to this template file. I'd like to keep the  
commented INI file structure to:
- keep the template file close to LCDd.conf
- extract lcdproc config model structure from the INI file structure
- be able to re-use the INI file parser that comes with Config;:Model 
  (the one that track comments with their parameter [1])

So the special config-model instructions would still be specified in 
INI comments. For instance we could have:

# Where can we find the driver modules ?
# IMPORTANT: Make sure to change this setting to reflect your
#            specific setup! Otherwise LCDd won't be able to find
#            the driver modules and will thus not be able to
#            function properly.
# NOTE: Always place a slash as last character !
#%% "-d" is a Perl regexp ensuring that a directory is used
#%% the match directive ensure that the NOTE above is respected
#% type=leaf value_type=uniline match:"\/$" assert:"-d" 
DriverPath=/usr/lib/lcdproc/

To produce LCDd.conf, a simple grep should be enough:

  grep -v -e '^#%' LCDd.template > LCDd.conf

On the config-model parser side:
- #%% lines will be discarded as "model comments in INI comments"
- #% lines will be used directly as config model specification. 
- '# ' lines will be used as doc
- '#Foo' lines will specify lcdproc parameters
- 'Foo' lines as well
- When #% lines are found, no special parsing of the doc is done 
  (i.e. do not try to infer parameter type and properties from doc)

The last point should take care of the "required space between "#" and 
key" hack.

Markus, does this fit what you have in mind ?

All the best

Dominique

[1] http://search.cpan.org/dist/Config-Model/lib/Config/Model/Backend/IniFile.pm
[2] http://search.cpan.org/dist/Config-Model/lib/Config/Model/Manual/ModelCreationIntroduction.pod

--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont     -o- http://ddumont.wordpress.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111026/6102c2b6/attachment.pgp>