Preparing GConf for the next generation (D-Conf related)

[Mikael Hallendal]

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/