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
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
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
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,
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
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
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
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?
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
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
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
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
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)
-
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
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,
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,
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
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo
