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

[Vlad Harchev <hvv hippo ru>]

On 8 Sep 2000, Owen Taylor wrote:

 Thank you for reply, I thought I'm in your kill-list.

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

 Yes, it can be reused.

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

  This point could be accepted if the following was true:
 1) All apps use libglade. Even if glade was much more powerful at describing
    gui, it wouldn't allow setting various useful arguments that can be though
    out. (Like text position in GtkEditable - since all GtkEditable are empty
    after creation), while widget arguments can be made to be applied when 
    widget is realized (i.e. as late as possible to maximize the chance of 
    having them fullfilled with data - i.e. when text was put in GtkEditable 
    or rows were added into clist).

 2) If app don't use glade, then it's open source. Unfortunately (?) this is
    true for most gtk apps since only a few of them are commercial.
 
>  - 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.)

 I agree, that modifying application's behaviour is slighly different task.
But since we are mainly discussing setting gtk widget's arguments, this
particlular disadvantage (controlling not only GUI, but app's behaviour)
doesn't apply. Also, I think we should restrict the set of
settable parameters only to default values for parameters, that can be
changed by the user by interacting with them using mouse and keyboard (e.g.
text position of GtkEditable or index of default
notebook tab in some dialog, or index of row selected by default in CList) or
those that are safe to change (like whether to show popup for GtkNotebook).

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

 I don't see any problem with this.

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

 Hmm, probably I didn't describe my idea in full in previous message. I was
thinking about dynamic exchange of information about widget's arguments and 
their meaning and values between already running program and editres-like app.
User activates special editres-like app, clicks on some widget in the 
target app's window, and widget returns info about all arguments it accepts
(type, description, value). From this information, glade-like "properties"
window is created, in which user can set the options he wish, and applies (and 
possible saves to rc file) changes. Of course, the "properties" window 
shouldn't list all basic properties like button's border width, but ones like 
"default font size for font selection dialog" etc - i.e. default values for 
parameters that are changeable by user (so, GtkContainer::border_width 
doesn't fall into this category).
  
> >  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.

 I agree with you here. Also, the presence of interactive gui tool for editing
parameters will smooth the danger of modifying values of arguments that do 
have slight interaction with program's 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? 

 No, I haven't heard about it. Just searched freshmeat and sourceforge and
found nothing. Could you give an URL?
 
> > 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.

 No problem here. We can make global property setter/getter a function that
will look into some hash where getters/setters will be registered, using 
argument name as a key into that hash, and pointer to the struct with two 
functions - setter and getter as value. All gdk modules will have to register
those setter/getters in that global hash in various _init() functions. So, I
see no problem at all with this.
 
>  2) In order to allow important features like:
>  
>    a) dynamic changes at runtime across applications

 I haven't explored how gnomecc notifies about change in theme, but solution
for dynamic notification is obvious - sending client message with agreed
format to all toplevel windows (or something like that, based on the sending
client message). So, no problem here.

>    b) notification on particular properties 

 May be I don't get you (may be you meant "ability to chain in
request for notification of property's change by user's code")? Anyway, if
global properties' getter/setter is implemented as I proposed above (i.e. when 
getter/setter functions for particular argument name are registered in some
hash), getter/setter functions will automatically be aware of the property's
change since they are the only way to get/set property's value).

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

 So, this seems wrong.

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

 I think I proved that every disadvantage you've listed above doesn't matter
since it's easily solvable (solution described). 
 What do you think about all this?

> Regards,
>                                         Owen

 Best regards,
  -Vlad