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
|
