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

[Vlad Harchev <hvv hippo ru>]

On 7 Sep 2000, Owen Taylor wrote:

 Hi,

> 
> Havoc Pennington <hp redhat com> writes:
> 
> > "Joshua Horvath" <jmhorvat home com> writes:
> > > Has any work been done on a scheme for setting the double-click timeout and
> > > other global options?  I was browsing through the archives and it seemed that
> > > someone wrote some code for this but I grabbed the latest CVS sources and the
> > > timeout is still hard-coded.
> > > 
> > > If someone is working on this, I'd like to request that the menu select timeout
> > > be configurable as well.  It's kind of silly to have to recompile GTK just to
> > > set this timeout to zero.
> > > 
> > > If no one is currently working on this, I wouldn't mind writing some code to get
> > > this into the 2.0 release.
> > > 
> > 
> > I think no one has really thought through how it should work.
> > 
> > One idea that's been tossed around is special X properties to be
> > shared by GTK+, Qt, and other toolkits for things like double-click
> > timeout. This gives us toolkit compatibility and also gives us a way
> > to be notified if a setting changes. Unfortunately it isn't a very
> > extensible or general-purpose configuration mechanism.
> > 
> > Another idea is that we would have some generic way to set GObject
> > arguments from gtkrc, and that some GObject(s) (I'm not sure which or
> > how this would work) would have arguments for the various settings.
> > This is more extensible but is GTK-specific and also there's some work
> > involved in modifying gtkrc from a GUI without messing up anything
> > people have put in there by hand.
> > 
> > Another random thought is to have some kind of "configuration storage
> > module" which would let you get/set GValues and get notification when
> > they change, and that could be mapped to GConf or to a simple config
> > file, depending on which module you load. But, this also has
> > disadvantages and issues probably. I guess the necessary API would
> > include an awful lot of the GConf API (not that the GConf API is
> > really that big, though, if you only allow get/set/notify).
> > 
> > The approaches could be mixed and matched in various ways.
> > 
> > The main task is probably to figure out how it should work, and
> > convince everyone else you are right. All the schemes sound pretty
> > easy to implement once you figure out the right way to do it...
> 
> 
> Thinking about this a bit, I think the right thing to do is
> to export a very simple configuration interface; something
> like:
> 
> GtkConfigDB *gtk_config_db_default    (void);
> gboolean     gtk_config_db_get        (GtkConfigDB          *db,
> 				       const gchar          *key,
>                                        GValue               *value,
> 				       GError              **error);
> gboolean     gtk_config_db_set        (GtkConfigDB          *db,
> 				       gchar                *key,
>                                        gint                  priority,
> 				       GValue               *value,
> 				       GError              **error);
> guint        gtk_config_db_notify_add (GtkConfigDB          *db,
> 				       const gchar          *key,
> 				       GtkConfigNotifyFunc   func,
> 				       gpointer              user_data,
> 				       GDestroyNotify        notify,
> 				       GError              **error);
> void         gtk_config_db_notify_remove (GtkConfigDB          *db,
> 				          guint                 notify);
> 
> Except for the priority argument to gtk_config_db_set(), this 
> basically a proper subset of the GConf API.
> 
> The priority argument basically is a stupid replacement for 
> the GConf idea of a configuration source paths and defaults.
> 
> It can either be:
> 
>  default priority - set by the app
>  rc priority      - set in a RC file  [ only the RC file reading
>                                         code would ever call set()
>                                         with this priority ]
>  user priority    - corresponds to an X property on a child
>                     of the root window.
> 
>  - Notification (at least initially), would only be allowed on
>    keys, not namespace segments.
> 
>  - It should be possible to write a GConf backend that mirrors
>    the X properties with a section of the GConf database.
> 
>  - The only types allowed initially would be int, bool, double, string.
> 
>  - This is _NOT_ meant as a configuration mechanism for applications,
>    it is _NOT_ meant as replacement for GConf, or even gnome-config.
>    It is meant as a simple configuration mechanism which is flexible
>    enough to be reimplemented on top of something else later.
> 
> Does this make any sense?

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

 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?

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


>                                         Owen

 I'm waiting any reply to this, especially from people considered primary gtk
developers.

 Best regards,
  -Vlad