avibrazil at gmail.com
Sat Dec 11 19:39:02 EET 2004
I was actually thinking about a "commond" backend between GConf and
I'm not sure if the KDE community will like to see KConfig classes
depending on GConf, because GConf seems dependent on Gnome libs:
$ rpm -q GConf2 --requires
Well, to add Elektra is also another dependency, but lighter.
Also, we are writting patches for other non-desktop software using
Elektra, like X.org (pre-desktop :-), /sbin/init, etc, which makes
these softwares integratable with other dekstop apps as well as, well,
regular desktop apps. And I believe GConf can't go as far (as low
level) as Elektra.
But only the backend is not enough. I can think about these needed points:
- Define a shared way to represent atoms like font, color, file, point
(?), rect (?), etc.
- Write the patches.
- Make both Gnome and KDE ecosystem reorganize their can-be-shared
configurations (wallpaper, widget fonts, web proxy, etc) under a
This is a big effort, but the resulting work will be very usefull, and
the Berlin wall will be gone, then we'll have just 2 mixed cultures
living in peace in the same neighbourhood.
The concept of Elektra was and is being designed for integrations like
this. To try to unify all this civilizations. Oh, and also cross
platform: Linux, BSD, Unix, Windows, Mac.
On 11 Dec 2004 17:13:05 +0100, nf <nf2 at scheinwelt.at> wrote:
> On Sat, 2004-12-11 at 06:07, Avi Alkalay wrote:
> > I was getting ready to dive in some integration work like this.
> > The idea is to somehow integrate GConf and KConfig, so a KDE app can
> > configure a Gnome app, and vice-versa.
> > When configuration layer is integrated, we can explore more shared
> > capabilities: common desktop settings like fonts, background,
> > screensaver. Plus shared user mail settings, browser proxy, bookmarks,
> > last documents, home page, etc. And also user prefered apps for
> > browsing, mail, terminal, etc.
> This is definitely a cool idea! "Less is more" or "one library is better
> than many" certainly is true for config-libraries like it is for
> I would start with evaluating whether gconf could serve as a backbone
> for the KDE configuration classes.
More information about the xdg