Re: INVALID vs. NULL values

[Havoc Pennington <hp redhat com>]

Frederic Gobry <frederic gobry smartdata ch> writes: 
> The core functionnality is working, but the client library is not as
> thin as expected, mainly due to the use of the glib: I don't have
> dynamic libraries, and using a single function of the glib causes
> almost the complete library to be linked in a program. I'll also try
> to improve this situation by splitting the glib files, so that only
> the requested functions are linked in.

There are two usual problems here, g_warning() etc. pulls in all the
g_log mess, and GMemChunk/GAllocator pulls in GTree and gmem.c and so
forth.

> Now that my PicoGConf works, I will have to implement a sort of
> graphical preference editor on top of it. One shortcoming of the
> current model is the automatic enforcement of additional constraints
> on the values (min/max values for integers, general constraints on
> strings,...). Is this something that will be addressed in a future
> version (extended schemas for instance) or is it a design choice ? 

It's a design choice. Having gconf enforce those values has a number
of problems:

 - gconf can't validate things in arbitrary ways, it could only 
   have a fixed set of limited validation methods, unless 
   there was a scripting language in the server or something
 - it would be slower
 - it would add a lot of complexity
 - if the constraints are in the schemas, apps really would have 
   to check anyway, since schemas can get lost due to sysadmin 
   error or whatever

I think we may add "hints" to the schemas in the future, which would
include things like "this string is a color name" or the min/max
values for ints, so that a generic prefs editor could display things
more nicely. But there wouldn't be any validation on the gconf level,
these would purely be hints to enhance the gconf-editor GUI.

You've seen gconf-editor in CVS, right?

Havoc