Re: is a value writeable?



Sorry for the confusion, I named the first db badly. Incidentally,
the defaults database(s) should also be readonly.

The ability to dynamically combine multiple databases into a 
common
view is one of the most powerful features of GConf. Here is one
possible database list:

Enterprise mandatory (readonly)
Region mandatory     (readonly)
Workgroup mandatory  (readonly)
Host mandatory       (readonly)
User                 (writeable)
Host defaults        (readonly)
Workgroup defaults   (readonly)
Region defaults      (readonly)
Enterprise defaults  (readonly)

Logically this is great, but in practical terms, this level of
complexity is inefficient.  The obvious consequence is that an
administrator will want to 'fold' databases together.  This
requires a mechanism to import values from other databases,
effectively mirroring them.

The GConf public API's don't support mirroring because there is no
API to specify one or more databases to be read/written.  One
possibility would be to use gconftool which does allow a source
database to be specified, but it must then be possible to write
the keys and values in a form so that they can be recovered.  An
additional 'import' option would then take a file and sets all
values in that file (Windows' regedit can also do this).

Colm.

>Delivered-To: gconf-list@gnome.org
>X-Authentication-Warning: icon.labs.redhat.com: hp set sender to 
hp@redhat.com using -f
>To: Dan Winship <danw@helixcode.com>
>Cc: Colm Smyth <Colm.Smyth@ireland.sun.com>, gconf-list@gnome.org
>Subject: Re: is a value writeable?
>From: Havoc Pennington <hp@redhat.com>
>User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
>MIME-Version: 1.0
>X-BeenThere: gconf-list@gnome.org
>X-Loop: gconf-list@gnome.org
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion of the GConf library <gconf-list.gnome.org>
>
>
>Dan Winship <danw@helixcode.com> writes:
>> > Yes, but then the value get() returns would not be modified, 
and your
>> > application should not change the setting that's currently in 
effect. 
>> > So setting it doesn't do you any good at all. Why do you want 
to set
>> > it in that case?
>> 
>> Oh, I was confused by the example; the readonly file name was
>> "workgroup_defaults", where "defaults" to me implies you can 
override
>> them if you don't like them, so I assumed changing the value in 
the rw
>> dir would do that, and that the message was pointing out the
>> difficulty in doing that. Now that I know the search order 
doesn't
>> work that way, it's obvious what the message is really talking 
about.
>> 
>> (I can't think of a replacement word for "defaults" that 
wouldn't be
>> ambiguous though.)
>> 
>
>I've been calling it "mandatory", so if you search from top to 
bottom, 
>you have:
>
>   - mandatory read-only settings
>   - user settings
>   - default settings
>
>You can have multiple databases providing any of those levels. So 
the
>idea here is to detect the case where you have a mandatory 
setting and
>gray out the option in the prefs dialog.
>
>Havoc
>
>
>_______________________________________________
>Gconf-list mailing list
>Gconf-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gconf-list






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