[rfc] KConfig Schema (was: Re: Experiences with KDE-CVS at LinuxWorldExpo)

[Luis Pedro Coelho]

Em Terça, 19 de Novembro de 2002 00:37, Marc Mutz escreveu:
> 1. A KConfigSchema validator that is run on the app's schema file on at
> build time and checks the schema for validity and then creates
> 1a. A konfigrc that contains all the declared config items with their
> default settings.
> 1b. A .h file containing a precompiled version of the schema to be used
> by a KConfig validator at runtime (while reading values and -
> optionally for debug purposes - while writing values).
>
> 2. Said KConfigValidator (part of kdecore).

I have thought of something similar and thought it would be nice if there was 
a way to generate an application specific AppOptions class.

This is what I had in mind:

instead of:

config->readEntry("user",defaultUser);
config->writeEntry("host","182.122.90.3");

you'd write:


AppOptions options * = AppOptions::self();

options->user();
options->setHost("182.122.90.3");

Advantages:

- no spellling mistakes
- the defaults are handled in one place.
- There are no type mismatches. If one option is a bool, you acess it as a 
bool.

I thought this would be described by a xml language.

There are some differences to the way I thought of handling types, but I am 
not familiar with the XML Schema std you seem to base your proposal on.

Anyway, here are my ideas:

There are simple, complex and restricted types.

1. Simple types:

The base is QString. 

Any type where you write a two-way conversation to QString is accepted. This 
is, in a way, like "deriving" from QString. There would be a couple of 
pre-defined types of course: all the c++ builtins + urls + enums + set

Just to expand on the last definition. An enum is like

enum myEnumType { a, b, c, d, e };

And now I can save whether we are in state a or b or c, etc. While a set is 
more like a flags list.

enum myFlags { a = 0x1, b = 0x2, c = 0x4, d = 0x8, e = 0x10 };

where there can be several active at the same type.

Every type you declare can be either "extern" or "internal." This will tell 
the config parser whether to generate the class or not. For example, you may 
decide you need to save an existing enum. You would declare it as extern. You 
may also decide that this enum just exists for configuration porpuses, 
therefore you declare in internal. This way the parser would generate the 
declaration of the enum + code to put it into strings and out of strings. 
Same for set.

You can add any type you want by adding conversations to already existing 
types. Imagine you want to declare myType which converts to int. You just add 
the code to do the conversation, no pb. In the end there would be a string of 
conversions until it is converted to QString for storage.

2. Complex Types

2.1 Composite Types:

	This is lists or vectors. No big deal, really.

2.2 Structs

	Structs are like c++ structs. For example, in kmail you could declare a 
structure which saves the options for a mail account. Structs may contain any 
type.

3. Restricted types

	This just builds upon any other type by adding validation code. For example, 
the code

	if (x < 0 || x > 100) return reject;
	return ok;

	Restricts type "int" to the range [0 .. 100]. 

This finishes type declarations.

The real declaration of options would allow you to give each option the 
following attributes:

	-type 
	this is the whole thing specified above. Types can either be declared in a 
single place, even imported from other files, or just declared inline. That 
means that while specifying what option xzy looks like you can declare a 
complete new type for it or you may say, this is from the type T declared in 
file T.config
	- name 
	This is the name under which it will be saved in the config file
	- comment 
	This is a short one liner about this option
	- description
	This is a longer description which may appear in the documentation.
	- default
	This is the default value 

Both the comment and the description should be English text (and subject to 
translation).

The big piece missing in my thinking is how to integrate all of this with 
QtDesigner. It would be very nice, to say the least, if it all of this helped 
to create configuration dialogs. Here is what I think should be necessary: A 
way to connect a widget to an option where for example a checkbox would be 
connected to a bool option. Automatic tooltips would come from the comment 
field and a what's this help might come from the description field. The Apply 
and Ok buttons would cause the configuration to be validated and saved. I 
haven't figured out if this is possible and how to do it yet.

HTH,
-- 
Luis Pedro Coelho

http://blogs.salon.com/0001523