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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]