From: Benjamin K. <xk...@no...> - 2005-03-28 22:11:59
|
I've made an initial attempt at porting Gaim to GConf. The patch is here: http://sourceforge.net/tracker/index.php?func=detail&aid=1172114&group_id=235&atid=300235 It's simple to select which preference system to use at compile time. If USE_GCONF is set, all preferences will obtained from GConf. If it isn't, the normal ~/.gaim/prefs.xml file will be used. In either case, accounts.xml and blist.xml will be the same as they always were. Known bugs: Existing preference settings are simply ignored. Why is this good? GConf is a very robust preferences library that is used by a variety of applications. (although mostly GNOME apps) The way preferences are stored is flexible. Although the default storage system is XML files, it could easily be a database on a central computer. System-wide preferences can easily be created and changed at any time. (Although Gaim allows this now, once a user has made a single change, they no longer get the benefit of system-wide tweaks.) Preferences can be "locked down" which means that an administrator can create a setting that can not be changed by a user. Gaim settings can be changed by other processes and be immediately updated in Gaim. For GNOME users, backing up your preferences is now just a little easier. GConf is used by many many applications, so it is very well debugged. (Although the existing Gaim preferences code looked very solid to me.) Most users won notice any change at all, and those that want to use the old system can simply compile it without GConf support. Gaim preferences can be fully documented and internationalized in the schema file. Why is this bad? Some people don't have GConf on their systems already, but use Gaim. They won't be pleased by having a new dependency. GConf is not a large new dependency, and most users probably already have it installed because many applications use it. Users who really mind can simply compile (or rebuild an RPM) without GConf support. Some people copy their prefs.xml file around to keep their different machines in sync with each other. This will break them. (Esp. when moving to and from windows machines.) I'm not sure how big of a deal this is. How often do you really change your preferences? accounts and blist is still maintained as an xml file in ~/.gaim. The gconf settings will be available in: ~/.gconf/apps/gaim/ and can be moved around, although it is a somewhat more manual process. GConf does run on Windows, and since most people running Gaim on windows do not compile it themselves, but download it from the Gaim web site, there is no reason not to make that version use GConf as well. Gaim is available from multiple sources. If a user is using one source (say... a distro package) and switches to another source (say... the Gaim homepage) they might end up switching from a GConf build to a non-GConf build. It'll be confusing for them when they lose all their preferences. (Or, load different preferences, or old preferences, or...) This is a problem. I'm looking for solutions. Robert McQueen suggests: Have an optional gconf dependency, when enabled but gconf is not populated, import prefs.xml, and if a gconf key is manually set, read/write prefs.xml in favour of gconf This is an interesting suggestion. This adds two new gconf keys. The first one allows a gconf import of settings from prefs.xml out of a user's home. The second makes Gaim not use GConf at all. An administrator could lock these keys down to turn off the initial import and stop users from using prefs at all if they desired. It would also mean that my patch needed considerable re-working since this would require that Gaim have code for both preference systems at the same time. I've probably missed a few points both pro and con. Comments? |
From: Kevin M S. <ke...@si...> - 2005-03-28 22:33:55
Attachments:
signature.asc
|
Benjamin Kahn wrote: > I've made an initial attempt at porting Gaim to GConf. The patch is > here: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1172114&group_id=235&atid=300235 <snip> > Some people copy their prefs.xml file around to keep their different > machines in sync with each other. This will break them. (Esp. when > moving to and from windows machines.) > > I'm not sure how big of a deal this is. How often do you really > change your preferences? accounts and blist is still maintained > as an xml file in ~/.gaim. The gconf settings will be available > in: ~/.gconf/apps/gaim/ and can be moved around, although it is > a somewhat more manual process. > > GConf does run on Windows, and since most people running Gaim on > windows do not compile it themselves, but download it from the > Gaim web site, there is no reason not to make that version use > GConf as well. > Windows GTK does not ship with GConf as it is a gnome component, and converting to GConf is not particularly useful given that no other Windows applications use it. It would add pointless overhead for Windows Gaim users, and make the manipulation of configuration files far more complicated for them. It would make more sense to use the Windows registry, but I am firmly against that as it is just as non-portable. Another problem is this breaks the -c flag, preventing the user from specifying an alternate location for their configuration settings. Right now, all settings are contained in .gaim, and you can create a totally new profile within the same user account merely by using 'gaim -c /home/kevin/.gaim-alt'. If the data's stored in GConf, this might work for the buddy list, accounts, etc, but the preferences themselves would fail. The other question is, does this break the Fedora changes that allow a configuration file to be placed in /etc that overrides default configuration options for Gaim's initial configuration in a profile? As far as I can recall Gaim is intended to function easily on a system without GConf, such as with KDE, or with another GTK based Desktop Environment. Gaim is not intended to be a Gnome program. I don't think adding another dependency just for the hell of it is justified on any platform. Kevin |
From: Robert M. <rob...@de...> - 2005-03-29 00:27:51
|
(here's a 2nd attempt at this post which is a) finished and b) sent to the list instead of simguy) I'm generally in favour of this proposal - I think that if a solid implementation of Gaim on GConf exists it will be snapped up by distributors such as RedHat, Novell & Ubuntu to make Gaim a better managed component of a corporate desktop. We don't have much to lose if we make it possible to have the existing preferences backend as a fallback, and provide an import of the existing preferences. Kevin M Stange wrote: > Windows GTK does not ship with GConf as it is a gnome component, and > converting to GConf is not particularly useful given that no other > Windows applications use it. It would add pointless overhead for > Windows Gaim users, and make the manipulation of configuration files > far more complicated for them. It would make more sense to use the > Windows registry, but I am firmly against that as it is just as > non-portable. Novell have hired Tor Lindquist (one of the main guys behind the Windows support of GTK and GLib) to port Evolution to Windows. He's already done CORBA and I think will do GConf too, and probably base it around storing keys in the registry. So in the near future, using GConf is likely to get us *better* integration with Windows, not worse. > Another problem is this breaks the -c flag, preventing the user from > specifying an alternate location for their configuration settings. > Right now, all settings are contained in .gaim, and you can create a > totally new profile within the same user account merely by using 'gaim > -c /home/kevin/.gaim-alt'. If the data's stored in GConf, this might > work for the buddy list, accounts, etc, but the preferences themselves > would fail. Even though I sync .gaim between my laptop and my desktop, I do it for the buddy list, accounts & logs. I'm not too fussed about the ability to continue using a prefs.xml - ideally my prefs would be subtly different between the two computers anyway (window positions and sizes). If we implemented the gconf key to allow overriding, we could also use the same code to use a normal prefs.xml. Alternatively, we can just store an alternative prefs tree elsewhere in GConf. It's not insurmountable. > The other question is, does this break the Fedora changes that allow a > configuration file to be placed in /etc that overrides default > configuration options for Gaim's initial configuration in a profile? No, gconf programs can register both a system-wide schema for their configuration values, and a system-wide set of defaults. That's where we got the idea from I think. :P > As far as I can recall Gaim is intended to function easily on a system > without GConf, such as with KDE, or with another GTK based Desktop > Environment. Gaim is not intended to be a Gnome program. I don't > think adding another dependency just for the hell of it is justified > on any platform. Using GConf doesn't make something a GNOME program any more than using Gtk does. It's a library and a daemon that stores configuration values for you, and is the default preference storage of the GNOME desktop, but this by no means precludes its use elsewhere. It's not for the hell of it, it's to reduce code duplication and provide us with more features, such as alternative storage backends, site-wide defaults, administrator control and system-wide defaults & locked down values. We could get the system-wide proxy setting with ease, and the choice of sound sinks/sources for GStreamer (which is on its way with audio/video conferencing work that marv is doing) are also stored in GConf. > Kevin Regards, Rob |
From: Ethan B. <ebl...@cs...> - 2005-03-30 13:18:52
|
First of all, I'm not sure I like the idea of migrating to GConf; how- ever, I'm not set against it, and I'm not going to fight about it. As a datapoint, though... Robert McQueen spake unto us the following wisdom: > > Another problem is this breaks the -c flag, preventing the user from > > specifying an alternate location for their configuration settings. > > Right now, all settings are contained in .gaim, and you can create a > > totally new profile within the same user account merely by using 'gaim > > -c /home/kevin/.gaim-alt'. If the data's stored in GConf, this might > > work for the buddy list, accounts, etc, but the preferences themselves > > would fail. >=20 > Even though I sync .gaim between my laptop and my desktop, I do it for=20 > the buddy list, accounts & logs. I'm not too fussed about the ability to= =20 > continue using a prefs.xml - ideally my prefs would be subtly different= =20 > between the two computers anyway (window positions and sizes). If we=20 > implemented the gconf key to allow overriding, we could also use the=20 > same code to use a normal prefs.xml. Alternatively, we can just store an= =20 > alternative prefs tree elsewhere in GConf. It's not insurmountable. I'd like to say that I generally agree here. Of course, I don't even copy my blist or accounts. ;-) > Using GConf doesn't make something a GNOME program any more than using=20 > Gtk does. It's a library and a daemon that stores configuration values=20 > for you, and is the default preference storage of the GNOME desktop, but= =20 > this by no means precludes its use elsewhere. It's not for the hell of=20 > it, it's to reduce code duplication and provide us with more features,=20 > such as alternative storage backends, site-wide defaults, administrator= =20 > control and system-wide defaults & locked down values. We could get the= =20 > system-wide proxy setting with ease, and the choice of sound=20 > sinks/sources for GStreamer (which is on its way with audio/video=20 > conferencing work that marv is doing) are also stored in GConf. This system-wide proxy setting argument brings up a good point. A sur- mountable point, but one which we would have to think about. What do we do if I don't use gnome? (Which I don't, of course.) It does make sense to use the gnome proxy settings for Gaim, as long as we have direct access to them ... but if we did that, it really means that we'd need to provide an interface to _change_ the gnome proxy settings and/or to choose _not_ to use them and to use our own. Either way is kind of ugly... (Note that I don't like the current plan of "use the gnome proxy set- tings iff gnome is running", either.) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Kevin M S. <ke...@si...> - 2005-03-29 00:37:26
Attachments:
signature.asc
|
Robert McQueen wrote: > Novell have hired Tor Lindquist (one of the main guys behind the Windows > support of GTK and GLib) to port Evolution to Windows. He's already done > CORBA and I think will do GConf too, and probably base it around storing > keys in the registry. So in the near future, using GConf is likely to > get us *better* integration with Windows, not worse. I don't think keys in the registry is any good. It's more complicated to back up the registry, and makes backing up your gaim configuration divided between two places. I've been constantly pleased by Mozilla for storing my preferences away from the registry, because I can back up my profile directory and have every part of my configuration come with it. To back up Microsoft Office settings, I have to find two dozen folders and thousands of scattered registry keys. I don't intend to use Evolution in Windows, but I plan to continue to use Gaim, and this seems to indicate that I'll be expected to have installed and running the GConf daemon all the time, for a single application. > Using GConf doesn't make something a GNOME program any more than using > Gtk does. It's a library and a daemon that stores configuration values > for you, and is the default preference storage of the GNOME desktop, but > this by no means precludes its use elsewhere. It's not for the hell of > it, it's to reduce code duplication and provide us with more features, > such as alternative storage backends, site-wide defaults, administrator > control and system-wide defaults & locked down values. We could get the > system-wide proxy setting with ease, and the choice of sound > sinks/sources for GStreamer (which is on its way with audio/video > conferencing work that marv is doing) are also stored in GConf. > I'm not sure I see how this would help in Windows so much, since proxy information isn't stored in GConf now, nor would any audio/visual information or anything else meaningful be. The code duplication argument doesn't make any sense to me either, because that's solved simply by reusing our XML code. The code for the preference system itself doesn't decrease much, does it? > Regards, > Rob Kevin |
From: Robert M. <rob...@de...> - 2005-03-29 00:48:03
|
Kevin M Stange wrote: > I don't think keys in the registry is any good. It's more complicated > to back up the registry, and makes backing up your gaim configuration > divided between two places. I've been constantly pleased by Mozilla for > storing my preferences away from the registry, because I can back up my > profile directory and have every part of my configuration come with it. > To back up Microsoft Office settings, I have to find two dozen folders > and thousands of scattered registry keys. I don't intend to use > Evolution in Windows, but I plan to continue to use Gaim, and this seems > to indicate that I'll be expected to have installed and running the > GConf daemon all the time, for a single application. Other Windows ports of GNOME applications like Abiword, GIMP, etc, will probably start expressing a dependency on GConf. Anyway, if you think it's bad on Windows that's fine - don't enable it. You're the one who makes the Windows ports. As a side point, the gconf daemon looks after starting itself and timing itself out when its not being used, so it's not cause for concern or added user complexity. > I'm not sure I see how this would help in Windows so much, since proxy > information isn't stored in GConf now, nor would any audio/visual > information or anything else meaningful be. That comment was more directed towards Linux desktops where Gaim currently has the really ugly property of requiring sound and proxy (and possibly browser) stuff to be configured independently of anything else and on a per-user basis. That really sucks. > The code duplication > argument doesn't make any sense to me either, because that's solved > simply by reusing our XML code. The code for the preference system > itself doesn't decrease much, does it? Admittedly we don't have a huge amount of code dedicated to preferences that's not used by blist/accounts/etc, but that wasn't really a huge part of my point. The point is that I think a large majority of Gaim deployments on Linux will be as a part of a GNOME desktop, and even if not, adding a single library people are *very* likely to have (GConf is a dependency of GStreamer, which is soon to be made a dependency of KDE...). Either way, it gets us great wins in terms of site or system-wide defaults and overrides, and makes Gaim a more manageable component of tens of thousands of desktop Linux deployments. > Kevin Regards, Rob |
From: Luke S. <lsc...@us...> - 2005-03-29 03:53:28
|
On Mon, Mar 28, 2005 at 04:33:53PM -0600, Kevin M Stange wrote: > Benjamin Kahn wrote: > > I've made an initial attempt at porting Gaim to GConf. The patch is > > here: > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1172114&group_id=235&atid=300235 > <snip> > > Some people copy their prefs.xml file around to keep their different > > machines in sync with each other. This will break them. (Esp. when > > moving to and from windows machines.) > > > > I'm not sure how big of a deal this is. How often do you really > > change your preferences? accounts and blist is still maintained > > as an xml file in ~/.gaim. The gconf settings will be available > > in: ~/.gconf/apps/gaim/ and can be moved around, although it is > > a somewhat more manual process. > > > > GConf does run on Windows, and since most people running Gaim on > > windows do not compile it themselves, but download it from the > > Gaim web site, there is no reason not to make that version use > > GConf as well. > > Initially I was very strongly against using gconf for gaim. I think, however, that it would be acceptable given the following: 1)we do not use gconf for windows. the windows registery sucks, and using gconf as a frontend to it will not decrease the suck. adding a daemon to windows is also distasteful. avoiding the registry or added complication on windows is a feature, and gconf would thus be a bug. 2)there MUST be an upgrade path. while I understand and accept that a corporate environment may want to lock down settings, this is not going to be the most common use case in the immediate future, but people upgrading their gaim and expecting their preferences to remain will. the upgrade path must thus be ON by default, an admin wishing otherwise must explicetly turn it off. 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. > > Windows GTK does not ship with GConf as it is a gnome component, and > converting to GConf is not particularly useful given that no other > Windows applications use it. It would add pointless overhead for > Windows Gaim users, and make the manipulation of configuration files far > more complicated for them. It would make more sense to use the Windows > registry, but I am firmly against that as it is just as non-portable. > > Another problem is this breaks the -c flag, preventing the user from > specifying an alternate location for their configuration settings. > Right now, all settings are contained in .gaim, and you can create a > totally new profile within the same user account merely by using 'gaim > -c /home/kevin/.gaim-alt'. If the data's stored in GConf, this might > work for the buddy list, accounts, etc, but the preferences themselves > would fail. 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. > > The other question is, does this break the Fedora changes that allow a > configuration file to be placed in /etc that overrides default > configuration options for Gaim's initial configuration in a profile? no, it should in fact make it stronger. > > As far as I can recall Gaim is intended to function easily on a system > without GConf, such as with KDE, or with another GTK based Desktop > Environment. Gaim is not intended to be a Gnome program. I don't think > adding another dependency just for the hell of it is justified on any > platform. 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. 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). luke > > Kevin |
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 |
From: Luke S. <lsc...@us...> - 2005-03-29 14:10:49
|
On Tue, Mar 29, 2005 at 02:31:20PM +0100, Robert McQueen wrote: > 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. Fair enough, my appologizes for being too harsh. luke > > Regards, > Rob |
From: Paul K. <pau...@gm...> - 2005-03-29 15:14:51
|
> 1)we do not use gconf for windows. the windows registery sucks, and > using gconf as a frontend to it will not decrease the suck. adding a > daemon to windows is also distasteful. avoiding the registry or added > complication on windows is a feature, and gconf would thus be a bug. As just a poor user at the moment, let me just throw a counts-for-very-little vote in for this. Ultimately I would like GAIM to run from a memory stick without touching the system HD (write wise). The abilty to not just move prefs but be able to run GAIM on "guest" computers without leaking stuff onto those guest computers would be very handy. PK |
From: Mark D. <ma...@ki...> - 2005-03-30 01:12:13
|
On Mon, 28 Mar 2005 17:11:34 -0500, Benjamin Kahn wrote > I've made an initial attempt at porting Gaim to GConf. The patch is > here: I suppose I should chime in. I like to keep things terse, so here are some random and comments. 1. Benjamin, I appreciate your very thorough email. Nicely done. 2. I glanced at the patch, it looks ok to me. I know nothing of gconf. Your code looks pretty good. There is a crazy amount of "#ifdef USE_GCONF" checks, but I suppose that's the best way. Also, personally, if a gconf patch is applied anywhere, I think I would want to see it only applied to head and not to oldstatus (the 1.x.x branch of CVS). 3. gconf DOES have a lot of neat advantages, but I wonder if they would be used widely. It almost seems like gconf is being promoted because it does fancy things that computer-savvy people appreciate (instead of being promoted because it's practical and a necessity). Can anyone give some first-person, real-world examples where the use of gconf by Gaim would have made things easier on them? 4. The thought of maintaining both the old and the new prefs systems doesn't appeal to me. If we do decide to use gconf, I think I'd like to see us ALWAYS use gconf everywhere. And if gconf in Windows doesn't work well enough to be usable then I'd rather not see it used anywhere. Bleh, this email is too long. At least my sentences are short. I'm going climbing pretty soon, yay! -Mark |
From: Luke S. <lsc...@us...> - 2005-03-30 02:09:18
|
On Tue, Mar 29, 2005 at 08:13:01PM -0500, Mark Doliner wrote: > On Mon, 28 Mar 2005 17:11:34 -0500, Benjamin Kahn wrote > > I've made an initial attempt at porting Gaim to GConf. The patch is > > here: > 2. I glanced at the patch, it looks ok to me. I know nothing of gconf. Your > code looks pretty good. There is a crazy amount of "#ifdef USE_GCONF" checks, > but I suppose that's the best way. Also, personally, if a gconf patch is > applied anywhere, I think I would want to see it only applied to head and not > to oldstatus (the 1.x.x branch of CVS). I tend to agree here, head only. > > 3. gconf DOES have a lot of neat advantages, but I wonder if they would be > used widely. It almost seems like gconf is being promoted because it does > fancy things that computer-savvy people appreciate (instead of being promoted > because it's practical and a necessity). Can anyone give some first-person, > real-world examples where the use of gconf by Gaim would have made things > easier on them? Novell currently applies a patch to gaim to remove certain preferences from the UI, forcing defaults, resisting attempts to edit the prefs.xml (If I understood the patch correctly). This would remove some of the need for that patch, they could set up the preferences in the gconf root config and then lock them. Beyond that, it would also be useful in a coproprate environment where users do not have root. there may be other real world cases I am not thinking of. > > 4. The thought of maintaining both the old and the new prefs systems doesn't > appeal to me. If we do decide to use gconf, I think I'd like to see us ALWAYS > use gconf everywhere. And if gconf in Windows doesn't work well enough to be > usable then I'd rather not see it used anywhere. I still dislike the idea of dropping all support for the efforts to make gaim and its config fully mobile (someone emailed about using it from a usb key recently for example) even after an additional day's thought on the matter. that was my rationale for wanting both kept around. Reguardless of the decision on keeping the ability to write a prefs.xml, we should have an upgrade path, just as we did from .gaimrc to .prefs.xml. I do not think that this need of an upgrade path should block a move to gconf if we decide that the benifits outweight the costs or that the costs can be worked around in some manner. > > Bleh, this email is too long. At least my sentences are short. I'm going > climbing pretty soon, yay! enjoy your climbing :-) luke > -Mark |
From: Tim R. <tim...@co...> - 2005-03-30 02:43:49
|
Luke Schierer wrote: > Novell currently applies a patch to gaim to remove certain > preferences from the UI, forcing defaults, resisting attempts to edit > the prefs.xml (If I understood the patch correctly). This would > remove some of the need for that patch, they could set up the > preferences in the gconf root config and then lock them. Beyond that, > it would also be useful in a coproprate environment where users do not > have root. there may be other real world cases I am not thinking of. None of these people have actually wanted gconf enough to approch us asking about it, have they? Or should Kahn's @novell address imply that that's why he's writing the patch? > Reguardless of the decision on keeping the ability to write a > prefs.xml, we should have an upgrade path, just as we did from .gaimrc > to .prefs.xml. I do not think that this need of an upgrade path > should block a move to gconf if we decide that the benifits outweight > the costs or that the costs can be worked around in some manner. You also need a downgrade path, or else what happens if someone switches from gconf build to a nongconf build? Where did all my prefs go? But I UPGRAED to Gaim 1.10.0, because the topic said so! It sounds rather difficult to me to make a gconf ignorant build able to import prefs from gconf back to prefs.xml Also, what good is all this locking down prefs stuff, if I can just GAIM_USE_PREFSXML=1 ./gaim ? From the autopackager perspective, I think "one more think that ought to be made to use dlopen". All that said, I'm not totally gun ho against this. I just can't come up with anythign good to say about gconf that hasn't already been said. --Tim |
From: Felipe C. <fel...@gm...> - 2005-03-30 19:33:47
|
On Tue, 29 Mar 2005 20:13:01 -0500, Mark Doliner <ma...@ki...> wrote: > On Mon, 28 Mar 2005 17:11:34 -0500, Benjamin Kahn wrote > > I've made an initial attempt at porting Gaim to GConf. The patch is > > here: > > I suppose I should chime in. I like to keep things terse, so here are some > random and comments. :) > 3. gconf DOES have a lot of neat advantages, but I wonder if they would be > used widely. It almost seems like gconf is being promoted because it does > fancy things that computer-savvy people appreciate (instead of being promoted > because it's practical and a necessity). Can anyone give some first-person, > real-world examples where the use of gconf by Gaim would have made things > easier on them? Well, my first thought was extended preferences available for GConf, so someone can use a tool like the GConf editor for those. I suppose that's easier than to whatever option there is for extended preferences (I've never bothered to check that). > 4. The thought of maintaining both the old and the new prefs systems doesn't > appeal to me. If we do decide to use gconf, I think I'd like to see us ALWAYS > use gconf everywhere. And if gconf in Windows doesn't work well enough to be > usable then I'd rather not see it used anywhere. I agree on this one. But I would like GConf even on Windows. And BTW, backing up a settings tree on the windows registry is easy. Maybe not for something as Microsoft Office, which has scattered settings, but it certainly would be easy for Gaim. Altought I can't see why someone would like to do that so badly. -- Felipe Contreras |
From: Tim R. <tim...@co...> - 2005-03-30 23:02:05
|
Felipe Contreras wrote: > Well, my first thought was extended preferences available for GConf, > so someone can use a tool like the GConf editor for those. I suppose > that's easier than to whatever option there is for extended > preferences (I've never bothered to check that). I don't think switching to gconf would (or should) also imply adding a bunch of hidden prefs. --Tim |
From: Sean E. <sea...@bi...> - 2005-04-05 16:40:27
|
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 I: The changes made by the patch should be localized to prefs.c. I was told by someone (I forget who) that #ifdef's were added everywhere a preference was set or read; I just looked at the patch, and that's not true. Point I is moot. 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? 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). 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. 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. 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 necessity. 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. 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? -s. |
From: Luke S. <lsc...@us...> - 2005-04-05 23:04:21
|
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 side thread. > > 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 > necessity. 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 users. > > 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. luke > > 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? > > -s. > > > > ------------------------------------------------------- > 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. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
From: Ethan B. <ebl...@cs...> - 2005-04-05 23:29:54
|
Luke Schierer spake unto us the following wisdom: > 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 > users.=20 Perhaps more importantly, I would rather Gaim chose a solution than Debian and Novell chose a solution or, worse, chose different solutions. If this _is_ going to happen regardless of our choice, we should do our best to steer it in some direction we can digest. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |