Re: is a value writeable?
- From: Colm Smyth <Colm Smyth ireland sun com>
- To: danw helixcode com, hp redhat com
- Cc: Colm Smyth ireland sun com, gconf-list gnome org
- Subject: Re: is a value writeable?
- Date: Thu, 24 Aug 2000 12:26:19 +0100 (BST)
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]