Preparing GConf for the next generation (D-Conf related)
micke at imendio.com
Tue Mar 8 05:19:41 PST 2005
Philip Van Hoof wrote:
> On Tue, 2005-03-08 at 12:02 +0100, Mikael Hallendal wrote:
> I've been studying the current GConf code. And now you ask; my personal
> view on whats lacking/need to be removed from GConf is the following
> list of items*. Note that it's a personal view. It's my opinion so this
> doesn't necessarily means it's the truth.
> I wanted to learn and understand the current GConf code. The tearing
> GConf into pieces is part of my learning process. I might have named it
> "GConf-3" but I haven't yet said that it's indeed the future of GConf-2
> per sé. It's (as you stated in a prive mail) a playground to see what
> can be done with the current GConf-2.
I'm just saying that you shouldn't call it GConf-3 (not anywhere)
because all of the sudden someone is going to read it on a mailing list
and think that it's indeed GConf-3. Or even worth, people start using
your version and when the GConf maintainers start working on the real
GConf 3 (unless it's in fact the fork you've created) there will be a
huge bit of confusion involved.
> * The list
> Build environment
> GConf needs a clean build environment that isn't trying to build Gtk+
> sanitychecks or test applications if it can find a Gtk+ development
> environment. That isn't trying to make it also possible to build GConf
> with ORBit-2 as IPC (only support DBUS). That separates different
> build-targets also in directories rather than putting sources of the
> library, the sanity-check, the gconftool and the daemon in the same
> directory. That has clean and maintainable Makefile.am and configure.ac
Problem with doing this is that you'll be unable to produce an
reviewable patch since *everything* will have changed. If there is a
reorganization required it should be done in a seperate step imho.
> - The communication should be DBUS rather than ORBit-2. There's
> a prove of concept branch in GConf's CVS that will replace
> ORBit-2 with DBUS. But it's design is to replace ORBit-2 with
> DBUS with as few changes possible (for keeping the patch
> maintainable). I prefer calling this a prove of concept-hack.
Well it was never done as a proof of concept. It was done to be able to
use GConf on platforms doesn't have/want ORBit. Like for example a
platform such as GPE. This at the same time as requiring minimal
maintenance to keep up to date with new GConf releases.
> Further discussing the list of requirements seems to go in the wrong
> direction. It's becoming a thread which is basically saying that this
> new system is going to have to solve all of the problems in this world.
> This isn't true. In fact it has to focus on a very specific problem:
> handling the configuration of DESKTOP applications.
Hmm .. I still haven't seen any comments (from you or others) on the
requirements from KDE, OpenOffice.org, ... Without them it would be a
waste of time at this point to do major redesigning in GConf to meet
their (unknown) requirements.
Anyway, I'm not the maintainer of GConf so it's not really my headache.
Imendio AB, http://www.imendio.com/
More information about the dbus