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/ _______________________________________________ gconf-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gconf-list
