Re: Status of configurable global options (double-click timeout, etc.)?

[Havoc Pennington <hp redhat com>]

Vlad Harchev <hvv hippo ru> writes: 
>  As for b) It seems b) is very easy solvable problem. 

The question is, is there any point in going to much trouble to solve
it, given that it's simple to implement the API Owen presented in
about an hour.

>  There is no need to register all object's arguments in one function, so such
> registration could happen in several functions. As for getter/setter functions
> - I've already told that we can have a global GHash that should use argument's
> name as key and pointer to (or the very) struct with two functions - getter
> and setter. The _set_arg and _get_arg functions of that gobject holding global
> options will just look up the getter/setter functions in that hash, so
> implementation of getter/setter could be done in various files.
>

This is a big old hack that's hard to use and violates standard
GObject usage conventions.
 
>  As for c) gnomecc already deals nice with c) IMO - generated .gtkrc includes
> .gtkrc-mine at last line thus allowing to override anything. Similar approach
> could be used.
> 

Another gross hack, which breaks down if multiple apps edit
gtkrc. Also, it is inefficient to keep having all GTK apps reloading
gtkrc.

>  As for DB API - will it be possible to have app-specific values if
>  it's used?

Sure, you can put in any key you want.

You can also simply have GObject's with arguments for your
application. At issue is only what to use for GTK+ settings.

> I think it won't, but it would be very easy in gobject args-based
> approach.

If we have the global GObject with settings, it would be wrong to have
apps use that; they should create their own global GObject. And they
can still do that in any case with the DB API.

> Also, object args-based approach doesn't require gconf to be installed on the
> system (so there won't be any problems with windows or BeOS or Mac or QNX port
> of gtk).
>

Neither does the other approach, the DB API does not result in
persistent storage if you set a value via the DB API; it reads values
from gtkrc first, then from the X properties, then applications can
override with their own setting.
 
Havoc