Re: is a value writeable?

[Colm Smyth <Colm Smyth ireland sun com>]

>Delivered-To: gconf-list@gnome.org
>X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com 
using -f
>To: Colm Smyth <Colm.Smyth@ireland.sun.com>
>Cc: gconf-list@gnome.org
>Subject: Re: is a value writeable?
>From: Havoc Pennington <hp@redhat.com>
>
>Colm Smyth <Colm.Smyth@ireland.sun.com> writes: 	
>> the update will fail with GCONF_ERROR_OVERRIDDEN; however, there is
>> no way to find out in advance that a readonly value occurs before
>> a writeable database. When designing a GUI that will display GConf settings,
>> it would be useful to be able to indicate to the user which values are 
>> really
>> editable.
>>
>
>Definitely, good point.
> 
>> I see three solutions, all of which require small extensions to the
>> API:
>> 
>> 1) Create a new API GConfSources *gconf_sources_list(GConfError **err)
>>    to get the current list of GConfSources; an app can then use the
>>    gconf_sources_query_value() API to check each GConfSource to see
>>    which one contains the value. If the flags for the GConfSource indicate
>>    that it's readonly, assume that the value cannot be written to.
>> 
>> 2) Create a new API GConfValue *gconf_get_value_and_source(const gchar *key,
>>     const char **address, GConfError **err). Once the app knows the source
>>     address, it can use gconf_resolve_address() to get the GConfSource and
>>     if the source's flags indicate readonly, assume that the key cannot be
>>     written to.
>>    
>
>Note that sources or source lists are not currently exposed in the
>public API (the public headers are the ones that get installed,
>gconfinclude_HEADERS in gconf/gconf/Makefile.am). I would like to keep
>the public API all tied to conceptual features of an abstract config
>database and not bound to the specific implementation.

True, but adding these internal API's makes it easier to write the API's
below and might facilitate other API's. For example, a search option
in a gconfedit GUI should be done within the gconfd daemon, not by
having a client get all keys and values using the GConf public API's.

>(The "sysadmin" interface obviously has to know about the
>implementation, but I'd like to keep applications conceptual, both 
>to make it easier to write applications and to make it easier to 
>change GConf's implementation.)
>
>> 3) Create a new API gboolean gconf_writeable(const gchar *key, GConfError 
>> **err)
>>    Note that this cannot use the existing writeable method in the backend
>>    vtable as the client needs to know that the key is set as well as knowing
>>    if the database (or key) is protected.
>>        
>> Note that the backend interface permits individual keys in a database to be
>> non-writeable, even though the database itself is writeable.  There is
>> currently no way to test this with API's 1) and 2); an additional API
>> gboolean gconf_source_writeable(GConfSource *source, const gchar *key,
>> GConfError **err) is needed to expose this feature of the backend interface.
>> 
>
>In the public API (gconf.h) I guess I would like:
>
>  gboolean gconf_key_is_overridden (GConfEngine *conf,
>                                    const gchar *key,
>                                    GConfError **err);
>
>and the corresponding method on GConfClient.

The gconf_writeable() API has a slightly extended semantic to
gconf_key_is_overridden(). It checks for overridden keys as
well as checking if all writeable databases have this key
marked readonly (using the backend 'writeable' method).
The effect for a gconf client is identical, so I would
like to see both checks combined in one API checking writeability.

Colm.

>Internally, I think adding gconf_sources_key_is_overridden() in
>gconf-sources.h would be sufficient to implement this feature.
>
>> There is a workable 4th solution; get the value for the key and attempt to
>> set the key to the existing value.  If this succeeds with
>> GCONF_ERROR_OVERRIDDEN, then it is possible to change the value.  This will
>> work, but it's inefficient.
>>
>
>Yes this is "bad hack" territory, I'm sure application authors would
>find it distasteful, as they should.
>
>Havoc
>
>
>
>_______________________________________________
>Gconf-list mailing list
>Gconf-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gconf-list