Re: [Gaim-devel] Porting gaim to GConf

[Robert M. <rob...@de...>]

Luke Schierer wrote:
> 3)there SHOULD be a way to generate and use a prefs.xml.  IF it
> exists, it MUST be a seemless change, that is selecting to use the
> prefs.xml MUST automatically create a prefs.xml that accurately
> reflects the current settings.  this will allow us to continue to
> offer those who wish to maintain prefs across computers that are not
> all using gconf the ability to do so.  this MAY be something requiring
> the use of gconftool and an associated FAQ entry.  Alternately, it MAY
> be a drop down similar to the drop down for logging.

Having a *visible* preference to choose where your preferences are 
stored is absolutely ridiculous. If we can make a little script or 
something that reads gconf and recreates a prefs.xml that'd probably be 
most elegant - it would avoid the need to have code for building an XML 
prefs tree out of the gconf keys always loaded in Gaim. I think it's 
less important to be able to import preferences back out of GConf into 
prefs.xml than it is to just be able to say "keep them in prefs.xml" 
before you've made any changes. Hence this behaviour:
  * import prefs.xml to gconf if it exists and the initial import key in
     gconf has not been set
  * use prefs.xml and not gconf if the native prefs storage key in gconf
     has been set

This means in the two common cases of the user having a gconf binary and 
not knowing or caring where their preferences are, they don't get any 
confusion and a prefs.xml isn't created, or your Gaim power user who 
finds to their horror that their distribution's Gaim package has moved 
their preferences to GConf can go and read the FAQ and make Gaim just 
read/write the prefs.xml (*or* you can just compile it without gconf and 
have no problems).

> this does break the -c flag.  however, keeping logs in ~/.gaim/logs, a
> *hidden* directory, does not make the greatest amount of sense either.
> -c was done because of the frequent requests to have different
> profiles, with different enabled accounts.  this would still be
> possible.  alternately, if the above #3 is implemented, -c would still
> do *exactly* the same thing when said pref to turn off gconf is
> enabled.

I'd say that having -c on the command line should probably just skip the 
gconf code entirely, and create a prefs.xml in the indicated directory.

> right.  it has been.  And I consider this, and the fact that we can
> currently migrate *nearly* seemlessly (plugins being a hugely notable
> exception) across computers, and even operating systems, but would be
> significantly less able to do so with gconf to be the 2 downsides of
> such a move not addressed by the above.  #3 would do so, but only by
> loosing the benifits at the cost of still having a dependency for
> those using a gconf-built gaim.  it is frankly something that would
> need careful consideration before we accept this, consideration beyond
> robot101's gung-ho jingo-ism. 

I think accusing me of gung-ho jingo-ism is a *little* harsh. What I'm 
saying is that of all the things Gaim stores, my preferences are, in 
reality, the least important to me. Now that we have a lot of reasonable 
defaults, and not that many preferences at all, to restore them is a 
matter of ticking a few boxes and dragging my buddy list to where I 
wanted it. If I lost my logs, or my accounts file, or my buddy list with 
it's contact groupings, I'd have to spend a long time recovering or 
reconstructing the information.

That's the only reason why I'm suggesting that you're being a little too 
preoccupied with the "syncing .gaim between computers" use case. I do 
that, and I honestly wouldn't mind if the preferences were excluded - 
the overall benefits to having Gaim play along well and inherit defaults 
in a gconf-based desktop are far more appealing.

> Still, I believe this is a legitimate proposal and should be
> *considered*, not rejected on instinctual grounds.  we already have a
> significant number of #ifdefs for win32, done right, with wrapper
> functions around the gconf calls (to allow for the prefs.xml as per
> #3), this would not even mean a significant amount of intrusion
> (whereas the current patch, from what I understand, is).

Thinking more on a code point of view, adding a little shim to have a 
"prefs store provider" much like we have ssl providers and log providers 
would be quite elegant. The gtkmain code could make its choice between a 
prefs.xml file or gconf based on whatever we decide, and then register 
the appropriate provider with core, and this would be the only real 
place where IFDEFs sat in the main line of code. If you compile with 
gconf disabled, it just registers the native storage, and gaim proceeds 
as present. This would also open up the way for libgaim users to have 
the core store its preferences in whatever form they wanted, and let us 
implement a gconf backend with minimal disruption.

> luke

Regards,
Rob