nils.faerber at kernelconcepts.de
Thu Mar 22 14:26:16 CET 2007
WANG Gang RD-ILAB-PEK schrieb:
>> 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.
> I just removed the dependence on libxsettings from gpe-phonepanel,
> libsettings is used instead (for this moment libsettings relies on
>> Any volunteers?
> I think I will.
Perfect, many thanks!
I just talked to Florian about it and he came up with a good point for
We still have one possible area where we would like to have an
additional abstraction in settings, i.e. if we find that the to be
chosen config mechanism would not be suitable for all intended use
cases. This means in our curent discussion, can we think of situations
where GConf might not be desirable?
On possible caveat of GConf could be resource usage. Is this an issue?
If yes, when or where? Are there others? And could those be avoided
using an addtional abstraction which could possibly allow other settings
backends, like a simple text file? And would that really help?
The resource usage of GConf is indeed an issue. But we should research a
bit on that and find out how big the impact really is. Nokia resolved
that to a certain extend by using GConf on DBus. This is nice, not
exactly the slimmest method but already very good. But is GConf-DBus
upstream? Is it maintained?
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