nils.faerber at kernelconcepts.de
Thu Mar 22 13:46:06 CET 2007
WANG Gang RD-ILAB-PEK schrieb:
> Since there are lots of setting mechanisms lying around and being used, people always have to make their choices when they need a setting system. Just like IAC (Inter Application Communication), libsettings tries to bring a simple and easy to use interface to application programmers.
Right, and abstracting the different settings, as far as I understood.
Since we right now have to deal with xsettings, GConf and other settings
at the same time.
> We have had a similiar situation when dealing with IPC in our GPE Phone Edition and in earlier discussions in LiPS. Dbus finally overcome other candidates to be chosen as the basic IPC system in our G(PE)^2, but there still existed a craving for a simpler interface, hence IAC came into being.
> Or one step back, if we choose not to bring more chaos, ie, we stop developping and using libsettings but use one of the existing setting systems, GConf will be my personnal favorite since it is already part of GNOME and a lot of applications are using it. Backends support is also another plus to GConf (although xml is the only one for the time being, we can foresee other backends to be added in the future). APIs are also full-featured. And the schemas it uses is perfect for download-and-install which makes GConf a good choice for DM also.
It is not too late yet to choose *one* settings mechanism as a standard
for the rest of the project. I would just strongly recommend to adapt
all other components to that mechanism as well, i.e. trying to get rid
of xsettings and the others as much as possible.
In the long run this could make us even independant of X11 which is IMHO
a desirable goal. Not for now but later we might want to have a way
scaled down version which runs on DirectFB or GTK-FB. This is currently
near to impossible because of the heavy use of xsettings.
For the next step I would propose that someone - hehe ;) - takes a look
at *all* components in G(PE)2 and identifies
a) which settings mechanisms are already in place
b) what they are used for
c) if and how they can be replaced by e.g. GConf.
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48 Fax: +49-271-771091-19
D-57072 Siegen Mob: +49-176-21024535
More information about the Gpephone-devel