From: Robert M. <rob...@de...> - 2005-03-29 13:31:38
|
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 |