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

[Owen Taylor <otaylor redhat com>]

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?
                                        Owen