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

[Vlad Harchev <hvv hippo ru>]

On 10 Sep 2000, Havoc Pennington wrote:

> 
> 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.

 Why it's hard to use? What conventions? The implementation is invisible to
the programmer, so it doesn't really matter.

> >  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.

 Hmm, please elaborate - what did you mean by "if multiple apps edit gtkrc" -
the fact that at the same time several apps (instances of one app) can write
the same gtkrc (why?) or that there will be several different apps (tools,
not instances) that edit gtkrc. 
 Also, what do you mean by "all GTK apps reloading gtkrc" - the fact that they
load gtkrc when app starts or you think that the only way to apply changes at
runtime is to rewrite gtkrc and have all apps that use gtk to reload it? As I
described in some of letters in this thread, changes can be applied at
runtime by sending client messages (in format understood by gtk library) with
resource strings that have changed.

> >  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.

 It seems I was misunderstood - I meant whether that scheme will allow to set
values of arguments with application-precision (i.e. one double click timeout
value for gimp (resource string for it will look like 
	gimp.GtkProps.double_click_timeout: 0
) and another value for double click timeout for other apps, that will look
like
	*.GtkProps.double_click_timeout: 1
and so on). DB API could provide similar functionality, only if DB allowed to
do pattern-based matching of keys (not plain comparation).

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

 Yes, let's compose a list of global gtk parameters like double click timeout.

> > 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.

 It seems we should note distinction: if global gtk options are
resource-based, then gtk will _automatically_, without any support/request
from app, get correct values (possibly those values can be specific to 
applications, like double click timeout for gimp I mentioned above). If DB API
is used, then gtk will not _automatically_, without any support/request from
app, get correct values, since (I assume) DB API won't allow using patterns
as keys. Of course, using DB API, any app can request data for arbitrary key - 
but if it was coded for and/or told by user. I think we should assume that all
apps are infinitely stupid, not reverse, so "arguments of global options
object" approach is the only way to achive that required level of flexibility
IMO.
 Or we should define clearly that we don't need that level of flexibility and
forget about this thread (please, don't!).

> > 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.

 This seems interesting. Where I can read about DB API?
  
> Havoc
> 

 Best regards,
  -Vlad