Re: GConf vs. bonobo-config
- From: Havoc Pennington <hp redhat com>
- To: Dietmar Maurer <dietmar ximian com>
- Cc: Martin Baulig <martin home-of-linux org>, gnome-2-0-list gnome org, gconf-list gnome org, gnome-components-list gnome org
- Subject: Re: GConf vs. bonobo-config
- Date: 15 Jun 2001 16:44:10 -0400
Dietmar Maurer <dietmar ximian com> writes:
> Havoc Pennington wrote:
>
> > I haven't been complaining about bonobo-config much because I thought
> > we were using it as a GConf wrapper. However now it turns out that
> > isn't true, that we are using the bonobo-config flat XML file.
>
> No one wants to use the flat XML file for that purpose, thats simply
> wrong.
Sorry, I was looking at bonobo-config not bonobo-conf.
> > With code that's O(n) in the number of listeners, among other issues.
>
> AFAIK bonobo config contains a server side event filter, which reduces network traffic. As opposed to
> the GConf approach, where you send most changes through the wire.
No. GConf sends only changes that someone is actually listening to,
and only to those who are listening. Moreover it locates those who are
listening by doing a tree lookup instead of scanning a huge list.
> > And a completely unscalable XML backend.
>
> The xmldirdb backend is at least as scalable as the GConf one.
I meant "xmldb"
> > The database needs to be a database stack, to allow system defaults,
> > overridden by user settings,
>
> bonobo config can handle this.
So why isn't libgnome using it? How do I get the ConfigDatabase for
the default stack? Where is the implementation code for the database
stack so I can see how it works?
> > overridden by mandatory systemwide
> > overrides.
>
> I don't think we need that.
You think wrong.
> I have to agree that the code is newer, not as well tested and we
> need more documentation.
OK.
Let me bring up another issue:
* If the big advantage of bonobo-conf is avoiding C libraries, which
I agree is an advantage, what on earth are you thinking:
libbonobo_confincludedir = $(includedir)/bonobo-conf
libbonobo_confinclude_HEADERS = \
Bonobo_Config.h \
bonobo-config-database.h \
bonobo-property-frame.h \
bonobo-property-bag-proxy.h \
bonobo-property-editor.h \
bonobo-config-utils.h \
bonobo-config-control.h
libbonobo_conf_la_SOURCES = \
$(CORBA_SOURCE) \
gtkwtreeitem.h \
gtkwtreeitem.c \
gtkwtree.h \
gtkwtree.c \
bonobo-config-utils.h \
bonobo-config-utils.c \
bonobo-config-database.h \
bonobo-config-database.c \
bonobo-config-bag.h \
bonobo-config-bag.c \
bonobo-config-bag-property.h \
bonobo-config-bag-property.c \
bonobo-config-property.h \
bonobo-config-property.c \
bonobo-subproperty.h \
bonobo-subproperty.c \
bonobo-property-proxy.h \
bonobo-property-proxy.c \
bonobo-property-bag-proxy.h \
bonobo-property-bag-proxy.c \
bonobo-property-editor.h \
bonobo-property-editor.c \
bonobo-property-bag-editor.h \
bonobo-property-bag-editor.c \
bonobo-property-editor-basic.c \
bonobo-property-editor-boolean.c \
bonobo-property-editor-filename.c \
bonobo-property-editor-color.c \
bonobo-property-editor-option.c \
bonobo-property-editor-default.c \
bonobo-property-editor-enum.c \
bonobo-property-frame.h \
bonobo-property-frame.c \
bonobo-preferences.h \
bonobo-preferences.c \
bonobo-config-control.h \
bonobo-config-control.c
I don't see how this has gotten us anywhere.
I just fail to understand what crack is being smoked - there was no
need to reimplement all the work done for GConf, and there is no way
we can have two totally separate default config stacks in GNOME. It's
just broken in every way.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]