Re: Module proposal: dconf
On Tue, 2009-10-13 at 13:57 +0200, Cosimo Cecchi wrote: I think having GSettings merged in GLib is the blocker here for starting ports of application to the new infrastructure, as it happened with GIO. So the question about whether we should migrate all at once or not (for 2.30) depends on how soon this will be available in released packages of GLib. We came up for a roadmap for this in Boston. We have no fixed times, but it's well in-progress. I'd guess a month or so. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Tue, 2009-10-13 at 19:22 -0400, Alex Launi wrote: How far away are mono/python bindings? Can I use raw dbus is there are not client helper libraries? You can use raw DBus to interact with the dconf database -- there is a DBus service included in the release. For GSettings, it's not really a DBussable API, so no. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Tue, 2009-10-13 at 13:34 +0200, Rodrigo Moya wrote: I think it makes sense to do the migration for all the apps at once. Also, the migration from gconf can be done directly from dconf, the first time it starts, or even it could be clever enough to synchronize changes from gconf every time it starts, to cover apps that migrate to dconf later. That would remove the apps' responsibility to do the migration, which would be a lot of code to have that in all applications. I personally think migration is less critical than a lot of people think. Here's why (for me at least): - I often reinstall my distro when the new release comes out - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... - we're changing how our entire desktop looks/feels at the same time anyway, so the user will need to reconfigure that stuff (if they please) - it never takes me more than a few minutes of fiddling to get stuff back to how i like it in terms of settings. - doing some sort of automated migration encourages application developers to base their new settings schemas on the way they did things with GConf, rather than giving them a chance to have a 'clean break' and take full advantage of the new API (and also remove years of cruft). It certainly makes sense to provide some mechanism for applications using GConf to continue to function (note: this mechanism might be continue using GConf). For applications that get ported, though, *shrug*. I'm open to disagreement on this point :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Wed, 2009-10-14 at 14:00 +0200, Rodrigo Moya wrote: if dconf listens to changes in gconf, 3rd party apps would just need to link to glib/GSettings instead of libgconf, and their migration would be done automatically, right? dconf won't be made to listen to GConf. One alternative, though, is that a GSettings backend could be written that uses GConf (and its existing database) instead of dconf. This would allow applications to use the new API to access their existing settings in the existing database. dconf could be brought in later. I'm not sure this makes sense. You get (some of) the benefits of the nice new API but no performance improvements. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Wed, 2009-10-14 at 15:22 +0200, Matěj Cepl wrote: How is reading binary data faster than reading text data? (note, I don't fight for 570 tiny XML files at all). Using a binary file allows for the file to be mapped into the memory space of all client processes and read from directly in an efficient way, without locks. No roundtrips to get your config settings. You can't do that with text. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Thu, 2009-10-15 at 17:04 +0100, Michael Meeks wrote: So - at this point, I'd like to advertise FUSE gratuitously[1]; what with the ease of writing a FUSE filing-system, and the fact that we have a GVFS fuse mount already; it should be near-trivial to write a 'vi compatible' FUSE plugin there, that would show the configuration data as .ini style or fugly verbose gconf XML style or whatever ;-) At least, that's ok for the user XML, perhaps for the system, it's necessary to type some unbelievably verbose mount command-line to get the same effect - but hey; sysadmins are good at that right ? :-) That way we can have a sane data format, and the appearance of a text storage (and backup / restore / whatever) as well. Of course this should also take a clueful hacker all of - oh an hour or two to write ;-) Thanks for cutting to the core of the issue. This made me smile :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 10:00 -0400, Ryan Lortie wrote: On Tue, 2009-10-13 at 13:57 +0200, Cosimo Cecchi wrote: I think having GSettings merged in GLib is the blocker here for starting ports of application to the new infrastructure, as it happened with GIO. So the question about whether we should migrate all at once or not (for 2.30) depends on how soon this will be available in released packages of GLib. We came up for a roadmap for this in Boston. We have no fixed times, but it's well in-progress. I'd guess a month or so. Cool, thanks for all the hard work you've put in this :) Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, Oct 16, 2009 at 7:10 AM, Ryan Lortie de...@desrt.ca wrote: On Wed, 2009-10-14 at 14:00 +0200, Rodrigo Moya wrote: if dconf listens to changes in gconf, 3rd party apps would just need to link to glib/GSettings instead of libgconf, and their migration would be done automatically, right? dconf won't be made to listen to GConf. One alternative, though, is that a GSettings backend could be written that uses GConf (and its existing database) instead of dconf. This would allow applications to use the new API to access their existing settings in the existing database. dconf could be brought in later. That doesn't fix anything; it just delays an identical migration. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 07:35 -0700, Sandy Armstrong wrote: On Fri, Oct 16, 2009 at 7:10 AM, Ryan Lortie de...@desrt.ca wrote: On Wed, 2009-10-14 at 14:00 +0200, Rodrigo Moya wrote: if dconf listens to changes in gconf, 3rd party apps would just need to link to glib/GSettings instead of libgconf, and their migration would be done automatically, right? dconf won't be made to listen to GConf. One alternative, though, is that a GSettings backend could be written that uses GConf (and its existing database) instead of dconf. This would allow applications to use the new API to access their existing settings in the existing database. dconf could be brought in later. That doesn't fix anything; it just delays an identical migration. Why not letting existing installations continue using the GConf backend, and let only new installs use dconf ? Then you can provide a migration script or wizard that people can run if they want, but by default you stay in a very compatible mode. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, Oct 16, 2009 at 7:07 AM, Ryan Lortie de...@desrt.ca wrote: On Tue, 2009-10-13 at 13:34 +0200, Rodrigo Moya wrote: I think it makes sense to do the migration for all the apps at once. Also, the migration from gconf can be done directly from dconf, the first time it starts, or even it could be clever enough to synchronize changes from gconf every time it starts, to cover apps that migrate to dconf later. That would remove the apps' responsibility to do the migration, which would be a lot of code to have that in all applications. I personally think migration is less critical than a lot of people think. Here's why (for me at least): - I often reinstall my distro when the new release comes out If it would help we could get numbers from distros on how many users do upgrades vs clean installs. Also keep in mind users with a separate /home partition who do clean reinstalls but keep the same home directory. I really hope that our general user experience is better than completely wipe and reinstall every [six] months, but I don't have hard statistical data about what actually happens. - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... Let me take a quick look at what Tomboy stores: * A bunch of metadata related to synchronization that, if lost, requires you to start over, which an upgrading user might find to be a hassle * Formatting/linking preferences * List of pinned notes that always show up in tomboy tray menu * Global keybindings * Some keys used to determine if it's the first run So we can see that in the case of the application I maintain, the user would lose a few minutes fixing all of this. In the case of pinned notes, it could be a very frustrating thing since it's easy to forget what you had pinned, and while you could argue that this should not be stored in gconf, the fact of the matter is that right now it is. - we're changing how our entire desktop looks/feels at the same time anyway, so the user will need to reconfigure that stuff (if they please) I'm don't agree with this; how many of our user-facing applications are making drastic changes for 2.30? The only thing I can think of is the gnome-shell migration. - it never takes me more than a few minutes of fiddling to get stuff back to how i like it in terms of settings. As shown above, this is not true for every application. If there are other applications in a similar situation to Tomboy, these minutes add up. - doing some sort of automated migration encourages application developers to base their new settings schemas on the way they did things with GConf, rather than giving them a chance to have a 'clean break' and take full advantage of the new API (and also remove years of cruft). Good point. I hadn't even considered this. Could you please list the new features we can use? I did not see them in your original proposal. It certainly makes sense to provide some mechanism for applications using GConf to continue to function (note: this mechanism might be continue using GConf). For applications that get ported, though, *shrug*. As long as this is clearly communicated, it's not a big deal. I will not freak out if I have to do the migration myself, but I do think it's worth looking into a mass migration. I'm open to disagreement on this point :) Excellent ;-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 07:35 -0700, Sandy Armstrong wrote: That doesn't fix anything; it just delays an identical migration. Ya. I'm not particularly in favour of doing this either. It's just theoretically possible :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 10:07 -0400, Ryan Lortie wrote: I personally think migration is less critical than a lot of people think. Migration is important. An average user won't be too happy when they update their distro and find all of their settings have disappeared. Any arguments involving developers are basically irrelevant IMHO when it comes to migrations. Not providing a migration path will probably delay adoption of dconf/gsettings into Debian because Debian tries it's hardest to preserve user configuration, even during an update. There are long and scary scripts which can migrate gnome-panel 1.x to 2.x in Debian... Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
There are a number of difficulties if there is no proper migration of end users. - users often have forgotten the settings they made since they don't often upgrade their systems. (you as a developer is used to frequent update and things are generally fresh in memory, that makes it easier) - If the system admin has to set it up again for the user manually that will be a lots of supports calls. - Users do not get a good impression of the system should some important behavior changes without an easy fix. Of course, migration tools are generally only useful for a short period of time. If we do not plan it well, it will be literally a wasted efforts. That is by the times the majority of users have gotten the poor 'experience', they adjusted to it and moved on. Still, do we want to risk the GNOME reputation against obviously some hard works ? To probe a further further, are there measurable improvement in performance to switch from gconf to dconf/gsettings that can help us to justify the proposed changes [1]? -Ghee [1] I like to acknowledge that Ryan did some Great works here! Still these is a question I feel important to ask :) Ryan Lortie wrote: On Tue, 2009-10-13 at 13:34 +0200, Rodrigo Moya wrote: I think it makes sense to do the migration for all the apps at once. Also, the migration from gconf can be done directly from dconf, the first time it starts, or even it could be clever enough to synchronize changes from gconf every time it starts, to cover apps that migrate to dconf later. That would remove the apps' responsibility to do the migration, which would be a lot of code to have that in all applications. I personally think migration is less critical than a lot of people think. Here's why (for me at least): - I often reinstall my distro when the new release comes out - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... - we're changing how our entire desktop looks/feels at the same time anyway, so the user will need to reconfigure that stuff (if they please) - it never takes me more than a few minutes of fiddling to get stuff back to how i like it in terms of settings. - doing some sort of automated migration encourages application developers to base their new settings schemas on the way they did things with GConf, rather than giving them a chance to have a 'clean break' and take full advantage of the new API (and also remove years of cruft). It certainly makes sense to provide some mechanism for applications using GConf to continue to function (note: this mechanism might be continue using GConf). For applications that get ported, though, *shrug*. I'm open to disagreement on this point :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Module proposal: dconf
On Fri, Oct 16, 2009 at 3:03 PM, Ross Burton r...@burtonini.com wrote: Not providing a migration path will probably delay adoption of dconf/gsettings into Debian because Debian tries it's hardest to preserve user configuration, even during an update. There are long and scary scripts which can migrate gnome-panel 1.x to 2.x in Debian... I think we need some migration for things which are important (fonts) and/or highly user-visible (background) at a minimum. Now if we migrate gnome-panel then clearly those scripts have to get pretty scary. So the question isn't do we migrate or not, but how much do we migrate. -- Colin, who long ago wrote the first bits of those scripts, but if tasked with it this time would probably write them in something better than Perl ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
There has to be migration - i can never remember all my evo account settings and im sure in corporate environments it would be a major source of technical call outs If it were for only Gnome 3 then maybe an exception can be made but for gnome 2.x, migration is critical IMO jamie On Fri, 2009-10-16 at 16:14 +0100, Ghee Teo wrote: There are a number of difficulties if there is no proper migration of end users. - users often have forgotten the settings they made since they don't often upgrade their systems. (you as a developer is used to frequent update and things are generally fresh in memory, that makes it easier) - If the system admin has to set it up again for the user manually that will be a lots of supports calls. - Users do not get a good impression of the system should some important behavior changes without an easy fix. Of course, migration tools are generally only useful for a short period of time. If we do not plan it well, it will be literally a wasted efforts. That is by the times the majority of users have gotten the poor 'experience', they adjusted to it and moved on. Still, do we want to risk the GNOME reputation against obviously some hard works ? To probe a further further, are there measurable improvement in performance to switch from gconf to dconf/gsettings that can help us to justify the proposed changes [1]? -Ghee [1] I like to acknowledge that Ryan did some Great works here! Still these is a question I feel important to ask :) Ryan Lortie wrote: On Tue, 2009-10-13 at 13:34 +0200, Rodrigo Moya wrote: I think it makes sense to do the migration for all the apps at once. Also, the migration from gconf can be done directly from dconf, the first time it starts, or even it could be clever enough to synchronize changes from gconf every time it starts, to cover apps that migrate to dconf later. That would remove the apps' responsibility to do the migration, which would be a lot of code to have that in all applications. I personally think migration is less critical than a lot of people think. Here's why (for me at least): - I often reinstall my distro when the new release comes out - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... - we're changing how our entire desktop looks/feels at the same time anyway, so the user will need to reconfigure that stuff (if they please) - it never takes me more than a few minutes of fiddling to get stuff back to how i like it in terms of settings. - doing some sort of automated migration encourages application developers to base their new settings schemas on the way they did things with GConf, rather than giving them a chance to have a 'clean break' and take full advantage of the new API (and also remove years of cruft). It certainly makes sense to provide some mechanism for applications using GConf to continue to function (note: this mechanism might be continue using GConf). For applications that get ported, though, *shrug*. I'm open to disagreement on this point :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 15:15 +, Colin Walters wrote: On Fri, Oct 16, 2009 at 3:03 PM, Ross Burton r...@burtonini.com wrote: Not providing a migration path will probably delay adoption of dconf/gsettings into Debian because Debian tries it's hardest to preserve user configuration, even during an update. There are long and scary scripts which can migrate gnome-panel 1.x to 2.x in Debian... I think we need some migration for things which are important (fonts) and/or highly user-visible (background) at a minimum. Now if we migrate gnome-panel then clearly those scripts have to get pretty scary. So the question isn't do we migrate or not, but how much do we migrate. -- Colin, who long ago wrote the first bits of those scripts, but if tasked with it this time would probably write them in something better than Perl Can dconf import exported gconf xml? if so then its a non-issue and a migration script can easily be written using gconftool and dconftool if not I would suggest supporting that jamie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Le mardi 13 octobre 2009 à 13:12 +0200, Vincent Untz a écrit : Ryan is a bit sad to not get feedback on his proposal, so a bit more seriously: I think what we probably need is a migration plan. Should we move all the code from gconf to dconf in one cycle (if possible)? Should apps implement migration for the data in gconf? etc. There are a few traps that would be nice to avoid during the migration from GConf to GSettings: * keeping GConf as it is now - there are ~500 applications using GConf out there, not porting GConf means keeping it forever ; * having the user lose his settings and set up things again ; * having the developer of each application add migration code. Therefore a possible, sane transition plan looks like the following. 1. A new, source-compatible (if possible binary-compatible, but that’s less critical) GConf library is written on top of GSettings. All applications using GConf start using it together. 2. A migration tool is written to convert GConf data to dconf data. 3. This tool is used by distributors to make GConf schemas and system defaults available to dconf. (How it is done completely depends on the distribution.) 4. The tool is launched once by gnome-session. 5. An interface is provided so that an application can be ported from GConf to GSettings while still seeing the old data. To achieve that, either the data is not moved at all, or the API can specify an “old” location in GConf format as well as a “new” location in GSettings format. I’m afraid other proposed solutions will either shift the work on distributors (by keeping GConf without maintaining it), on users (by not migrating settings) or on developers (by letting them convert data themselves). Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Ryan == Ryan Lortie de...@desrt.ca writes: Ryan I personally think migration is less critical than a lot of people Ryan think. Ryan Here's why (for me at least): Ryan - I often reinstall my distro when the new release comes out [...] Ryan - it never takes me more than a few minutes of fiddling to get stuff Ryan back to how i like it in terms of settings. I'd like to ask that you also consider the needs of people for whom it is more work to reconfigure. I've had to reconfigure Gnome too many times already. This is a bad user experience! For one thing it has left me with the impression that Gnome assumes that my time is worth little. Tom ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 10:07 -0400, Ryan Lortie wrote: - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... I wouldn't be this sure; passwords usually aren't stored there, but e.g. mail accounts could be stored there, and I am pretty sure very few non-technical users know how to reconfigure their mail client on their own, and there could also be other similar examples. FWIW, I kind of like the migration path overview Josselin drafted in a previous mail. Anyway, we'd really need something like that. Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
2009/10/16 Josselin Mouette j...@debian.org Therefore a possible, sane transition plan looks like the following. 1. A new, source-compatible (if possible binary-compatible, but that’s less critical) GConf library is written on top of GSettings. All applications using GConf start using it together. 2. A migration tool is written to convert GConf data to dconf data. 3. This tool is used by distributors to make GConf schemas and system defaults available to dconf. (How it is done completely depends on the distribution.) 4. The tool is launched once by gnome-session. 5. An interface is provided so that an application can be ported from GConf to GSettings while still seeing the old data. To achieve that, either the data is not moved at all, or the API can specify an “old” location in GConf format as well as a “new” location in GSettings format. I like this proposal but, going back to the new module proposal for 2.30, could way say that dconf is in for 2.30 but that the above five points are not implemented until 2.32 to allow for a smooth transition and plenty of testing? That is, dconf and gconf would co-exist for 2.30.x, only. I don't see any value in trying to rush everything all at once for 2.30. If we can give app. developers plenty of time with dconf available but not mandatory, that would be preferable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
While not disagreeing with you on the need for migration * A bunch of metadata related to synchronization that, if lost, requires you to start over, which an upgrading user might find to be a hassle * List of pinned notes that always show up in tomboy tray menu * Some keys used to determine if it's the first run were the sort of things that were never meant to be stored in GConf because write access to the GConf DB is not guarenteed so the user cannot set anything. In these cases the keys used to determine if it's the first run could never be set, so it would always be the first run for the user, pinned notes would never be pinned and synchronization would always require you to start over. These things should have been stored with a GKeyFile in the ~/.config/Tomboy directory, IMO iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, Oct 16, 2009 at 10:19 AM, Iain i...@gnome.org wrote: While not disagreeing with you on the need for migration * A bunch of metadata related to synchronization that, if lost, requires you to start over, which an upgrading user might find to be a hassle * List of pinned notes that always show up in tomboy tray menu * Some keys used to determine if it's the first run were the sort of things that were never meant to be stored in GConf because write access to the GConf DB is not guarenteed so the user cannot set anything. In these cases the keys used to determine if it's the first run could never be set, so it would always be the first run for the user, pinned notes would never be pinned and synchronization would always require you to start over. These things should have been stored with a GKeyFile in the ~/.config/Tomboy directory, IMO If that's the case, I'll happily migrate them there. Thanks for the info! Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 18:19 +0100, Iain wrote: While not disagreeing with you on the need for migration * A bunch of metadata related to synchronization that, if lost, requires you to start over, which an upgrading user might find to be a hassle * List of pinned notes that always show up in tomboy tray menu * Some keys used to determine if it's the first run were the sort of things that were never meant to be stored in GConf because write access to the GConf DB is not guarenteed so the user cannot set anything. In these cases the keys used to determine if it's the first run could never be set, so it would always be the first run for the user, pinned notes would never be pinned and synchronization would always require you to start over. These things should have been stored with a GKeyFile in the ~/.config/Tomboy directory, IMO People say that, but I think most applications do just assume the settings in GConf are writable. I know I don't have any code to disable the preferences in Yelp if the settings aren't writable. The only use case I can see for read-only settings is a lockdown setup, e.g. for a public Internet terminal. And in that case, I'd make the home directory read-only as well, so the whole point is moot. Regardless, many applications store useful information in GConf, whether we think that's right or not. Losing all that data would seriously suck. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Hi! OK, lets face on our problems again: * We want to get rid of gconf for 3.0 because we want API/ABI-compatibility over the whole 3.0 cycle which can be long. Gconf is (more or less) unmaintained at the moment. If we keep it for 3.0 things would likely get worse. * It is definitly important to keep the user settings over the transition. So at least any setting that is mentioned in a schema file has to be migrated (others are buggy, right?). I cannot say how to do this but I think it is possible. * We can only fix core-GNOME stuff. Of course 3rd party apps will still require gconf sometimes and distros will have to keep it around anyway (they even keep gtk+-1.2...) I hope the dconf/GSettings guys will come up with some migration strategy because the are likely the only ones that know about technical details. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Sat, Oct 17, 2009 at 1:09 AM, Johannes j...@jsschmid.de wrote: * It is definitly important to keep the user settings over the transition. So at least any setting that is mentioned in a schema file has to be migrated (others are buggy, right?). I cannot say how to do this but I think it is possible. I hope the dconf/GSettings guys will come up with some migration strategy because the are likely the only ones that know about technical details. I think we need to pay attention to Ryan's comment that the GSettings conversion should be an opportunity for apps to tidy up their schemas and use the new features gsettings allows. It's a dead end doing a blind gconf-gsettings schema conversion: just think about how much richer a type system gvariant is compared to gconf's, for example. I know I've committed various hacks around the gconfvalue's limitiations and I'm sure there are examples in many gnome apps. With that in mind, the app is going to need a certain amount of involvement in the migration progress. I suggest that when an app migrates to gsettings, it provides a mapping in some form of the gconf schema to the gsettings schema. A tool can read this and migrate any settings in gconf to dconf when the new version is installed - either in 'make install' or as a post-install hook in distro packages. A couple of points about this: - it needs to flag once it has done the conversion, so that old gconf settings don't overwrite new dconf settings each time the package is upgraded. - the mapping only needs to mention gconf keys that don't have an obvious analogue in the gsettings schema - this gives app developers the minimum amount of work while allowing them to use new gsettings features Sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 15:13 +, Colin Walters wrote: So the question isn't do we migrate or not, but how much do we migrate. Let pragmatism win the day :) -- Colin, who long ago wrote the first bits of those scripts, but if tasked with it this time would probably write them in something better than Perl Are you suggesting that you might want to be tasked again with something along these lines? :) Seriously, though -- help in this regard would be very much appreciated. I have a whole lot of stuff on my plate right now. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
