Wrapping up

[Havoc Pennington <hp redhat com>]

Dietmar Maurer <dietmar ximian com> writes: 
> Another question is the used default configuration database, "gconf:" or
> something else. But this belongs to another mail.
> 

Sure. So if we use the gconf: database by default, then bonobo-config
is a wrapper. 

But to go back to the original starting mails in this thread, that
means that GConf is _required_ for gnome-libs 2, not optional.
configure should bomb out if you don't have it. Because users will
lose all their settings if they install without it, and sysadmins
won't be able to admin settings.

Again, my objection is to incompatible config databases (xmldb,
xmldirdb, etc.), not to our syntax flavor of the month (G*, Bonobo*).
Reimplementation = bad, wrapper = fine.

Also, I would insist that we install GConf schemas for all our config
keys. This is something that Nautilus really needs to do as well.
I don't think bonobo-config as wrapper will currently successfully
retrieve GConf docs? That needs fixing.

I do also caution against putting CORBA_any in the config database,
but that was extensively hashed out on gconf-list, and it seems people
put programming convenience ahead of all other concerns on this point.

Finally, I would make a general comment that we need to be working on
usability and performance of the desktop as our primary goal. Example:
biggest current Nautilus performance complaint is opening a new
window. Top of the profile for this operation is mucking around with
UI handler XML nodes. But our current plan is to port e.g. Gnomine to
the same UI handler code.  So why are we reimplementing GConf instead
of fixing the UI handler? Do we need a Gnomine that uses a couple megs
and takes 4 seconds to come onscreen?

To avoid Michael's rage, I'll also use a GTK+ example: GObject has
serious bloat issues, e.g. signals are the slowest thing you've ever
seen, or e.g. the docs for properties are all gratuitously
strdup()'d. Tim rightly wants to finish the API before addressing
this, but I'm biting my nails anxiously. I hope this will be a
higher-priority issue than some of the other things we might do.  I
think it may require us to remove some of the features of libgobject,
or hardcode some things that are currently done generically.

Anyhow, let's get our priorities straight and consider what's really
important.  GConf code may be kind of ugly, but much of that ugliness
stems from user-benefitting features such as the ability to have
workgroup-wide settings, or error handling/logging (useful error
messages!  horrors!), or efficiency. (Some of the ugliness is just
stupid mistakes, of course. I'm the first to admit it.)

Code cleanup and programmer convenience can't be at the expense of
important features or reasonable performance. When scheduling time to
hack on a new feature, finishing it and maintaining it have to be
included in the time estimate. We aren't spending enough time on
adding the error handling, writing the test suite, doing the bugzilla
management, etc., all those boring details.  Being a hacker is more
than typing in code 24/7.

Havoc