A draft for a standard for desktop configuration
bastian at kde.org
Tue Sep 13 00:26:38 EEST 2005
On Monday 12 September 2005 14:36, Philip Van Hoof wrote:
> On Mon, 2005-09-12 at 14:32 +0200, Philip Van Hoof wrote:
> > You can find the proposal itself (it's source) here:
> > http://cvs.pvanhoof.be/cgi-bin/viewcvs.cgi/desktop-config-standard/
> If you don't have the tools installed to build the PDF:
> Note that this is the 'current' version. The contents might change in
> future, don't refer to it.
Comments for section 5.2:
Please use $XDG_DATA_DIRS/configuration as defined by
instead of hardcoding /usr/share/configuration
Comments for section 5.3:
KConfig supports almost any utf8 sequence as key, with a small number of
exceptions such as '=', '[' and low ascii. In particular '-' and space are
often used in key names used by KDE applications.
Comments for section 5.7:
1) The schema definition misses support for defining enumerations as type.
Suggest to add:
<!ELEMENT enum (choice*)>
<!ATTLIST enum name CDATA #REQUIRED>
<!ELEMENT choice (description*)>
<!ATTLIST choice value CDATA #REQUIRED>
name attribute of an enum can be referred to in the name attribute of a type.
The enum element can be a child of the node element so that a single enum can
be used for multiple schema.
2) It's unclear what the item attribute of the schema element is for.
Comments for section 6.2:
Including type information at the transport level makes it impossible to
support backends that do not provide type information such as KDE's .ini
files. I do not see the value of typing at the transport and backend level,
especially since the type information provided covers only a subset of all
the desired configuration types in a configuration system. The schemas
already provide much more detailed type information about keys, including
Comments for section 6.5:
It should be possible to change multiple values in a single atomic (logically
speaking) operation. Something like SetValues(STRING root, DICT data)
mirroring the GetValues call from 6.4.
Comments for section 6.9:
Instead of sending a signal for each key I suggest to change the signal to
KeysChanged(STRING root, ARRAY OF STRING keys)
KeysChanged(STRING root, DICT data)
mirroring the GetValues call from 6.4. With the distinction that for each root
a separate signal is send (no keys from "sub-groups" are to be included)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050912/527fc687/attachment.pgp
More information about the xdg