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

[James Lamanna <jlamanna its caltech edu>]

Owen Taylor wrote:

> 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?
 
Yes, this makes a lot of sense. In fact, I've actually used something
similar to 
this before in a server I helped write (it was a "ConfigurationReader"
object).
In the rc file, we could give it a look&feel similar to Xresources by
using the same types of conventions (i.e. GdkValue.doubleClickTimeout =
500 ...etc).
Also, I think a GUI interface to this rc file would be pretty easy.

I think that we definitely want to keep this thing simple, since we
don't want
to 'reinvent the wheel' too much (in terms of GConf...), but it does
give us a 
definite starting point.

James