Re: [Gaim-devel] Configuration API

[Luke S. <lsc...@gm...>]

On Tue, Dec 10, 2002 at 08:25:10PM -0300, Nicol?s Lichtmaier wrote:
> After some chat in the IRC channel, I've set myself the mission of 
> trying to improve the configuration system.
> 
> Currenty, gaim has a configuration system which seems to have the 
> following main goals:
> 
> * Instant setting activation.
> * Minimum *bit* overhead.
> 
> I'd like to remove the second goal. What I propose is a system where 
> each pref has a name, and it's retrieved with a function. My idea would 
> be to model the system to be similar to gconf, so that it gconf support 
> can be a ./configure option.
> 
> The API could resemble this:
> 
> gboolean get_bool_pref(GQuark pref);
> void set_bool_pref(GQuark pref, gboolean value);
> 
> GQuark is a way to be able to optimize things. It's like an "atom" in 
> other systems. It can be viewed as a string.

GQuarks aren't bad, i disagree with some of the api limitations, but 
that probly wouldn't affect prefs. 

> 
> The pref names (represented by GQuark's) would be hierarchical:
> 
> /sound/nice_sounds
> /misc/debug_window
> 
> (In gconf they would be prepended with /apps/gaim ).
> 
> There would be a system which will enable parts of gaim to register some 
> function pointer to be called when a property changes. As the most 
> important use for this would be to update a local variable, I propose an 
> API like this one:
> 
> gboolean myProp;
> int handle = track_bool_pref(GQuark pref, &myProp);
> while( ... ) {
> 	// we use myProp a lot here
> }
> dont_track_pref(handle);
> 
> When using gconf this will allow instant change of things when somebody 
> edits prefs with a gconf editor. Avoiding the overhead of querying the 
> pref each time the user types a key.

Robot101 spent alot of time removing gnome #ifdefs. now we have win32 
inserting a new set of #ifdefs. i do NOT want a 3rd set of #ifdefs, and 
i equally do not want to force gaim to depend on gconf. 

> 
> For the not-gconf version I would use two GData variables. One for the 
> pref values ("all_prefs") and one for the default pref values 
> ("all_default_prefs"). The getter functions would first query 
> "all_prefs", and then fallback to "all_default_prefs". This way there 
> could be buttons to reset prefs to "factory defaults" (they will just 
> remove the value in "all_prefs"). And the prefs which are not touched 
> will be able to change between gaim versions. But if the user has edited 
> the pref, then it would override the default (until the user reset the 
> pref).
> 
> Having an API like this one will make very easy other improvements, like 
> smarter gaimrc saving.
> 
> Well.. any thoughts? I must go now, bye! =)
> 

some of this probly would not be problematic, excect for timing. we just 
had prefs rewritten, and the bugs are still being worked out of it. 
introducing a new backend is, in my opinion, asking for trouble. 
secondly, as i said above, i do not like the idea of depending on gconf, 
and i like the idea of another set of #ifdefs even less. 
luke