is a value writeable?



Hi,

When reading values from GConf, it is usually an advantage that an 
application
neither knows (nor cares) which database from the user's database path
a particular GConfValue comes from. However when an application wishes
to update a GConfValue, it becomes important to 

Let's say that you have the following database path:

xml:readonly:/shared/gnome/gconf/workgroup_defaults
xml::/home/colm/.gconf

If workgroup_defaults contains a key /gnome/desktop/backdrop, then
if a user application does

	gconf_set_string("/gnome/desktop/backdrop", 
"/home/colm/coolpic.gif")
	
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.

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

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.

I would suggest adding all of the API's above as they are all
straightforward to implement.

Colm.






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]