Re: Module proposal: dconf
Rodrigo Moya wrote: On Tue, 2009-10-13 at 23:06 +0200, Luca Ferretti wrote: 2009/10/13 Rodrigo Moya rodr...@gnome-db.org: 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. I think it makes sense to do the migration for all the apps at once. Are we speking about: a) all GNOME Desktop applications b) all applications hosted on git.gnome.org c) all GNOME/GTK+ apps using GConf :) ?? Serius: what's the plan for thirdy part applications? 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? If dconf listens to changes in gconf, does not 3rd party apps would just work? This is a question of run-time interoperability, is dconf inter operate with gconf clients? Please clarify this. I can see lots of reasons why 3rd party doesn't want to re-link to glib/GSettings :) -Ghee ___ 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 Thu, 2009-10-15 at 11:24 +0100, Ghee Teo wrote: Rodrigo Moya wrote: On Tue, 2009-10-13 at 23:06 +0200, Luca Ferretti wrote: 2009/10/13 Rodrigo Moya rodr...@gnome-db.org: 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. I think it makes sense to do the migration for all the apps at once. Are we speking about: a) all GNOME Desktop applications b) all applications hosted on git.gnome.org c) all GNOME/GTK+ apps using GConf :) ?? Serius: what's the plan for thirdy part applications? 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? If dconf listens to changes in gconf, does not 3rd party apps would just work? This is a question of run-time interoperability, is dconf inter operate with gconf clients? Please clarify this. I can see lots of reasons why 3rd party doesn't want to re-link to glib/GSettings :) this is for doing the migration, once apps are ported to GSettings API (and hence not linking against libgconf), their settings should be in the dconf database automatically, because dconf migrated them That's how I would see it ___ 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 10:54 -0500, Shaun McCance wrote: No doubt. But ask that same question of sysadmins, and you'll probably get a different answer. 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 ;-) HTH, Michael. [1] - though, I'm not at the lets use it for all database queries type wide-eyed end of the spectrum ;-) -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
According to our rules only maintainers can propose their modules, but I assume that Jürg is more than okay with desrt's proposal as he did not answer with a No way! to this thread. ;-) andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
Andre Klapper wrote: According to our rules only maintainers can propose their modules Even for external dependencies? Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
Am Freitag, den 16.10.2009, 02:25 +0200 schrieb Emilio Pozuelo Monfort: Andre Klapper wrote: According to our rules only maintainers can propose their modules Even for external dependencies? Ah. Very good point. I should not try to catch up with 500 emails late at night. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
