On Tue, Apr 05, 2005 at 12:40:55PM -0400, Sean Egan wrote:
> On Mon, 2005-03-28 at 17:11 -0500, Benjamin Kahn wrote:
> > I've made an initial attempt at porting Gaim to GConf.
> This thread died down, so I'll resurrect it.
> Point II: There's a difference between introducing GConf and using GConf
> by default. If we decided to introduce GConf code, should we use it if
> GConf exists, or only if --enable-gconf is given to ./configure?
I tend to assume that as Novell, RH, and Debian are all likely to
enable this by default, we need to evaluate it as if it were enabled
by default period.
> Point III: Either way, this doesn't explicitly add a dependency (it
> can't, as Windows doesn't have gconf yet). However, packagers are forced
> to decide whether or not to add a dependency to their binary packages.
> That's not really much our concern, but answering "How do I get rid of
> the buddy list tooltip?" will suddenly require us to know what each
> binary package does (actually, we'd just need to ask them to check Help
> > About, but it's still a hassle).
Right, we also need to worry about people moving from the package
their distro made to one we make, or to compiling gaim themselves.
Will we just say "you loose your preferences, ahwell"? if its a
configure switch, we don't have a migration path, another reason why I
tended to approach this assuming it was enabled by default.
> Point IV: Rob McQueen says that adding a "preference backend" plugin
> akin to SSL plugins and whatnot would be "elegant." While he's correct
> in saying that these types of plugins are elegant in allowing this sort
> of thing to be specified at runtime, instead of compile-time, I'd say
> that an abundance of special-casing is inelegant.
perhaps we should simply have a generic flag for loading plugins
automatically instead of having special cases? but that's really a
> Point V: Most of the issues regarding moving plugins around can be
> solved by maintaining a prefs.xml even when using gconf, and perhaps
> adding a timestamp to see which preferences are more recent. You
> probably won't be happy, though, when your sysadmin changes all your
> preferences, and next time you use Gaim on Windows, you discover too
> late that logging has been turned off. That's probably not a good idea,
> then. I guess the only real solution for people who want portable prefs
> is not to use GConf.
right. which is why the thread diverged several times into a
discussion of how to handle this sort of thing. there is no 'good'
way to ever leave gconf.
> Point VI: The advantages that GConf has are interesting, and pretty
> cool. I think it's kinda neat that you could change your preferences
> from the command line, for instance. However, I can't really think of
> any reason why I'd consider it actually useful. I'm sure it's useful for
> sysadmins to put lock downs on their users, but I'm not sure I actually
> consider that an advantage. I'm sure Novell, RedHat, et al consider it a
from the command line? the only use I could see is to write a script
that automatically changes your prefs when your laptop changes its
profile, putting something in the post up scripts for your internet
connection to change your proxy prefs and such. our existing gconf
use would do this for gnome users, since we import the preference via
gconf's command line tool, but this would allow it for *all* gaim's users
(on gconf builds of gaim).
more realistically, the benifits were to let other applications change
preferences, and to let the sysadmin lock things down.
Rob McQueen said in #gaim when this was first proposed that these
benifits would quite possibly be enough to cause him to consider
this patch independently of us if we reject it, it is quite likely
that Novell would do the same (they patch gaim to hack locked down
preferences already), and less likely but still possible that RH
would similarly independently eval this patch. As distasteful as
this thought is, and as much as it reaks of being strong-armed,
it does provide incentive to accept this patch after stipulating
changes to minimize the headaches it could cause for us and our
> Point VII: I don't really like having two possible disjoint code paths.
> Although both preference backends seem very stable, things will break
> (see: recent GLib problems causing lost preferences), and this will make
> it harder to figure it out. I similarly don't like not knowing where
> people's preferences are being kept.
indeed, this is a valid point that I had not particularly thought of.
> Conclusion: I'm worried about the complexity this potentially adds, and
> I don't think the advantages are really that important. I think that, as
> it stands, I'd accept the patch, but require that --enable-gconf be used
> to enable it, rather than detecting if it's available like we do for
> most dependencies. That way anyone using GConf knows beforehand what
> they're getting into and if anyone's surprised when things don't work
> the way they used to, it's their own fault. Unless of course, distros
> enable GConf (I get the feeling Debian will), but then it's the distro's
> fault, still not ours.
> Importing prefs from GConf, as I plan to do with the URL handler and
> proxy settings, will still be done, the way I intend. If this patch is
> accepted, it will add an #ifdef as well.
> Does this sound like a good solution to anyone else?
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Gaim-devel mailing list