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

[Havoc Pennington <hp redhat com>]

Vlad Harchev <hvv hippo ru> writes: 
>  Why it's hard to use? What conventions? The implementation is invisible to
> the programmer, so it doesn't really matter.
>

It's visible to us working on GTK+. It's visible to app programmers if
they add their own settings.
 
>  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. 

Several tools.

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

Which is enormous complexity and mess. Right now the way the control
panel works is that it sends a client message to get all apps to load
gtkrc. Some elaborate hack to send object arg change notifications via
client messages is just not worthwhile.
 
>  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

As far as I'm concerned this is totally useless. There is no reason to
have per-app doubleclick timeouts.

> "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!).
>

GTK is not in the business of providing people with hackish ways to
work around broken apps, especially since most apps written with it
are free software. I don't think we need that level of flexibility.

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

By "DB API" I mean Owen's proposal.

Havoc