Re: [Ekiga-devel-list] Trunk sources
On Wed, Jun 2, 2010 at 9:43 AM, Julien Puydt jpu...@free.fr wrote: Le 01/06/2010 23:50, Peter Robinson a écrit : On Tue, Jun 1, 2010 at 8:37 PM, Julien Puydtjpu...@free.fr wrote: Le 01/06/2010 18:50, yannick a écrit : Le mardi 01 juin 2010 à 15:50 +0200, Julien Puydt a écrit : Well, it uses it through dbus, as far as I know -- so indeed it doesn't binary-depend on it, but should nicely use it when available. Then I probably mistaken this: did not Matthias used HAL for the hotplug device system? Yes, HAL through DBUS. So it's using HAL, but since it does it through a proxy, we don't binary depend on it. At least that's how I understand it. Also while we're on the topic of obsolete libraries what is the plan for migrating from GConf to gsettings as that is also on the chopping block for gnome 3? It might be a worthwhile time to review the settings code as I think there's some custom gconf style code to deal with windows as well, not sure if there's a windows backend for gsettings at all, but if so it might be a nice way to unify that bit. Here is how things work in ekiga : - we have an abstraction called gmconf, which is used all over ekiga ; - we have a gconf implementation of that abstraction, with a nice XML schema file containing the default settings ; - we have a glib implementation of the abstraction, which is able to read the schema file, and is portable -- that one is used when gconf isn't available, like for win32. That means porting to GSettings should be pretty straightforward -- porting the big gconf schema file is what worries me most, but since it's XML, it should be possible to do it automatically. There's gsettings-schema-convert [1] and other tools to help make the transition as painless as possible so they should be able to help. Will be interesting to see if someone writes a gsettings backend for the windows registry :-) Peter [1] http://library.gnome.org/devel/gio/unstable/gsettings-schema-convert.html ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Trunk sources
Le mercredi 02 juin 2010 à 10:05 +0100, Peter Robinson a écrit : On Wed, Jun 2, 2010 at 9:43 AM, Julien Puydt jpu...@free.fr wrote: Le 01/06/2010 23:50, Peter Robinson a écrit : On Tue, Jun 1, 2010 at 8:37 PM, Julien Puydtjpu...@free.fr wrote: Le 01/06/2010 18:50, yannick a écrit : Le mardi 01 juin 2010 à 15:50 +0200, Julien Puydt a écrit : Well, it uses it through dbus, as far as I know -- so indeed it doesn't binary-depend on it, but should nicely use it when available. Then I probably mistaken this: did not Matthias used HAL for the hotplug device system? Yes, HAL through DBUS. So it's using HAL, but since it does it through a proxy, we don't binary depend on it. At least that's how I understand it. Also while we're on the topic of obsolete libraries what is the plan for migrating from GConf to gsettings as that is also on the chopping block for gnome 3? It might be a worthwhile time to review the settings code as I think there's some custom gconf style code to deal with windows as well, not sure if there's a windows backend for gsettings at all, but if so it might be a nice way to unify that bit. Here is how things work in ekiga : - we have an abstraction called gmconf, which is used all over ekiga ; - we have a gconf implementation of that abstraction, with a nice XML schema file containing the default settings ; - we have a glib implementation of the abstraction, which is able to read the schema file, and is portable -- that one is used when gconf isn't available, like for win32. That means porting to GSettings should be pretty straightforward -- porting the big gconf schema file is what worries me most, but since it's XML, it should be possible to do it automatically. There's gsettings-schema-convert [1] and other tools to help make the transition as painless as possible so they should be able to help. Will be interesting to see if someone writes a gsettings backend for the windows registry :-) Peter [1] http://library.gnome.org/devel/gio/unstable/gsettings-schema-convert.html ssam wrote a windows backend for gsettings last summer: http://ssam.livejournal.com/9604.html I did not find new updates since then: http://gitorious.org/gsettings-gtk/gsettings/commits/windows-registry Best regards, Yannick ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Trunk sources
On 31/05/10 15:47, Eugen Dedu wrote: Hi, Now, that 3.2.7 has been released, we focus on trunk :o) The next release will probably be taken from ekiga master/trunk. The question is what do we take for ptlib/opal. Will we take: - trunk - or current stable branch, ptlib v2_8 and opal v3_8, released as stable beginning of May 2010? I think it is wiser to take the stable branch. Otherwise said, the next ekiga unstable release will be based on ekiga master, ptlib/opal current stable branches (not trunk!) Do you agree? As nobody disagreed, I propose that all people involved in ekiga development use ptlib/opal v2_8/v3_8 stable branch for ekiga master, ok? I have already updated http://wiki.ekiga.org/index.php/Download_Ekiga_sources -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Trunk sources
On 01/06/10 07:41, Thierry Simonnet wrote: Le 31/05/2010 15:47, Eugen Dedu a écrit : Hi, Now, that 3.2.7 has been released, we focus on trunk :o) The next release will probably be taken from ekiga master/trunk. The question is what do we take for ptlib/opal. Will we take: - trunk - or current stable branch, ptlib v2_8 and opal v3_8, released as stable beginning of May 2010? I think it is wiser to take the stable branch. Otherwise said, the next ekiga unstable release will be based on ekiga master, ptlib/opal current stable branches (not trunk!) Do you agree? I use trunk version of opal/ptlib. I've no big trouble for compiling and using it. I've much more trouble with ffmpeg and x264. I understand. But from my experience I know that bugs appear very easily, and ekiga needs to be tested continuously. For example, it seems the notification does not work anymore (the API changed), could you see if your contacts are online or away? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
