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

[Owen Taylor <otaylor redhat com>]

Vlad Harchev <hvv hippo ru> writes:

>  As for my opinion (that was ignored by gtk developers all the time), I think
> that we should provide a thing similar to X resources to gtk applications (but 
> not only for X port, but for all). Granted, it's possible to get name of the 
> widget's type, and even get name of the widget (if it was set) - all we need 
> is to either hack in some code from Xlib (that performs matching) if it's not 
> already implemented in gtk in gtkwidget.c. All widget's arguments should be
> controlable via some sort of rc file, and to add more flexibility, we should 
> add more arguments for standard widgets (I already have a list of useful
> arguments, but I won't share it until someone replies at least to a part of
> my messages on this list).

GTK+ of course, already has an RC file mechanism, with mechanisms
for matching against widget classes and paths.

There has been a fair bit of discussion here about extending this
mechanism to allow setting widget arguments. This is in fact,
how we want to go about setting arguments that affect a theme.

For instance, to allow setting the scrollbar width. Setting 
these options on a per-widget basis is necessary, since themes
themselves are per-widget. And the matching facilities for
setting some options should be the same as the matching
facilities for styles.

>  For example, to set the current position in the text of some gimp
> dialog, user will have to insert the following into his rc file:
> 
>  gimp.SomeDialogname.GtkVBox.GtkText.text_position: 32
> 
> Looks like X resource, isn't it? (For those who don't get it yet -
> there is a object's argument of GtkEditable with name 'text_position').

The trouble with X resources, is that they are a nice flexible 
mechanism, and are used for a lot of things, for none of which
they are perfect.

 - They are used by the application developer to change properties
   of the application as it is developed. But they aren't nearly
   as powerful or convenient in doing this as glade.

 - They are used to set options for applications:

    XTerm*scrollbar: false

   But this is just a bad idea, since Xresources are not machine-editable,
   do not allow presenting the user with a nice user interface,
   and don't allow 99% of the nice things that a good system
   like GConf allows. (Database backends shared between machines,
   change notification, etc.)

 - they are used to set various options that go across applications,
   such as font, background color, etc.

Your example above seems to fall into the "developer" class, something
that I have no interest at all in supporting. While there are
some neat hacks you can do in this regard to customize your X
apps (e.g., remove items from the netscape toolbar), in general,
it presents the power user with 99 ways to break a program compared
to 1 way to not break the program, and presents the normal user
no power at all.
 
>  Another example, having added that to rc file, 
> 	 *.GtkNotebook.enable_popup: true
>  all GtkNotebook's will have 'enable_popup' argument set, that is, all
> notebook widgets will popup menu with the list of tabs to allow instantly
> switching to some particular notebook page. Isn't it nice?

Sure, that's sort of nice. Except when you set turn off some
feature that the program is relying on. Setting arguments in
an RC file really needs to be restricted to arguments that have
no interaction with the programs logic.
 
>  We can even add support for dynamic querying of widget names (and arguments)
> - so we will have something to editres, to dynamically browse widget tree
> (flashing currently selected widget), to query widget's arguments
> and probably to change them. 

Have you, by any chance, looked at GLE? 

> Since all arguments are set using widget-supplied function, there is
> no need for API similar to GConf (for notification, etc).
 >
>  As for doubleclick timeout:
> IMO there should exist a single instance of object, that will be dedicated for
> setting/reading various options of gtk and gdk. Having done that, a lot of
> problems are solved:
> 
> * It's easy to override some parameters for a given program, by adding
>   something like that to rc:
> 	gimp.GdkParams.double_click_timeout: 0
> 	*.GdkParams.double_click_timeout: 1
> * There is no need for GConf-like API (a common advantage for X-resource-like 
>   approach), since setting/getting parameters is done by using function that
>   was registered by the object.
>
> * It's easy to control parameters by providing defaults, and have user-specific,
>  language-specific, and application-specific values.
> 
>  The drawbacks:
>  It's somewhat difficult to change some parameter for all widgets at runtime-
> for example, if user interactively requested to show popup menu for all
> GtkNotebook widgets, the only apporach to "instantly" satisfy user's request
> is traversing all created GtkNotebook's and call g_object_set() for them. But
> that's not a problem, but inconvenience - since it's present for any
> configuration mechnism.

Since we _are_ planning to add the facility to set properties to
the RC file, using a global object and setting properties on it
is one possible way of doing this.

However, I think it has various disadvantages:

 1) All properties need to be handled in one big global property
    setting functions. In order to add "triple-click-time" to
    GDK, I have to go and modify the global property object
    code.

 2) In order to allow important features like:
 
   a) dynamic changes at runtime across applications
   b) notification on particular properties 

  I have to add extra APIs on top of of the standard property
  API. So, I've lost the sense that I'm "just using properities"

Therefore, I think it is cleaner to go with a simpler interface
for handling global properties that isn't confused with an
interface for setting object properties.

Regards,
                                        Owen