Re: init clarity needed

[Havoc Pennington <hp redhat com>]

Darin Adler <darin bentspoon com> writes:
> There are a lot of init functions for a program to call in GNOME 2. I'd like a
> little help learning about them.
> 
> I assume that programs need to call some or all of these functions:
> 
>      gtk_init
>      gnome_program_init
>      bonobo_init
> 
> Which functions should I be calling in my programs? How can I decide which
> program should call which of these?

Theoretically gnome_program_init() is the big uber-init-wrapper that
handles calling all the others, IIRC.

> Also, for gnome_program_init, which properties do my programs need to pass in?
> And do I really need to make an explicit choice between xmldb and gconf for every
> program's config URI? What about test programs that don't really want persistent
> config storage?

If we allow a choice here it is broken. config: should simply point to
GConf and apps should use config:. Apps that want something else
should hardcode xmldb:, but there shouldn't be special support for
that in GNOME, because we don't encourage it.

> I hope someone can help me figure this out. So far, working this bit out has been
> the one of the hardest parts of getting the eel library to work under GNOME 2.

Init functions are Evil and should in general not exist. Most of the
ones we have we should not have. The #1 sign that an init function is
totally broken is that it has no arguments (e.g. g_type_init()).
Because if you have no args then you could have just called the darn
thing automatically in your library.

gtk_init() is perhaps OK, because it needs to connect to the display,
and this has to happen before anything else in GTK. But this doesn't
mean all libs should copy it. And even GTK could autoconnect to the
display the first time you used GDK without all that much hassle,
though perhaps that wouldn't be ideal.

The other typical motive for an init function is to parse args. This
is semi-justified, but how many libs actually have args? And when they
do, a simple foo_lib_parse_args() that only parses args and has no
other side effects is better than an init function, really.

Also, you can frequently use an env variable instead of needing to
parse args.

The problem with init functions is that the application has to know
about all the libs that will be used by it and anything it links to or
dynamically loads. Which is just a huge PITA and a maintenance
problem. It also tends to cause libs to do things on startup instead
of lazily, which leads to slow startup times.

For example, gnome-vfs will just call gconf_init() if it hasn't been
called, which is on crack, because if gconf_init() was actually needed
(and it really isn't), then it would be important to call gconf_init()
only at application startup time, so it could get argc/argv. Since
gconf_init() is actually useless, gnome-vfs calling it is harmless,
but there is no reason anyone should have to call it. I believe all
gconf_init() does these days is call oaf_init().

Anyway, basically init functions are a maintenance headache and hard
on app developers and there is no reason we need them in general.

gnome_program_init() is an attempt to bring sanity to the init
function mess but really we shouldn't have the mess in the first
place.

Havoc