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: 
> >  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.
 
 I don't get last sentence - we are talking about global gtk and gdk options,
how app programmers can grow the set of those options? If they are going to
grow it, then it's much more ugly hack than any solutions you call hack here.

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

 I think some functionality like this would be needed in the future when there
will be ability to set widget's arguments from resources-like strings and when
nice intuitive successor of editres I described in my previous letters will
exist.

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

 There are a pile of other global gtk options, the values of which would be
nice to precisely configure on per-app basis. For example, a list of gtk
modules to load, default visual (as I've heard, XFree4 allows several visuals
at the same time, so this can matter), probably theme, etc.

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

 OK, nice that you've expressed you opinion explicitly. As for DB API for
global options, it seems that it will be easy to have support for app-specific
values for global options (as double click timeout for gimp) just by looking
first a key with name of the app prepended, and then, if nothing is returned, 
the name of the key without appname prepended. In fact there is no need to
support pattern matching in DB when looking up values for global options using
DB API, since the "path" will be exactly 1 or 2 "elements" long (i.e. with
name of the app and dot prepended , or without them). The matters are 
different for widget's arguments, whose full "paths" can be long since
their "paths" name each container widget, so it won'tbe possible to use DB
API.

> >  This seems interesting. Where I can read about DB API?
> >   
> 
> By "DB API" I mean Owen's proposal.
 
> Havoc
> 

 Best regards,
  -Vlad