Preparing GConf for the next generation (D-Conf related)
Mikael Hallendal
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:
Hi,
> 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
> files.
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.
// M
--
Imendio AB, http://www.imendio.com/
More information about the dbus
mailing list