Xfce Forum

lano1106

Member

Registered: 2012-03-27

Posts: 4

xfconf architecture design goals question

Hi,

This is my first post on this forum as I started to play with xfce only since last week. I got interested into your window manager because I was looking for a really really slim Window manager and compared with metacity and kwin, xfwm wins easily by several order of magnitudes in terms of memory footprint!

By having chosen to mess with the prefix option with the configure scripts, on my first few attempts to launch xfwm, it didn't work immediately. I had to resolve problems related to D-bus not finding a xfce service in .service files.

Then some properties weren't found by xconf (Had to move the keyboard shortcuts xml file).

So on one hand, I have found my journey totally fascinating as I was not exposed at all before to the whole d-bus daemon thing but on the other hand from my xfce neophyte perspective what I am seeing is this:

xfwm goes through dbus daemon to launch a service process to read some xml config file.

From my neophyte perspective, that sounds over designed to just read some xml config file. What are the benefits of doing things like you do that justify going through dbus to read some config?

Thank you and keep doing the great work!
Olivier

lano1106

Member

Registered: 2012-03-27

Posts: 4

Re: xfconf architecture design goals question

I just had this other though. Even this sounds complicated. This is little beer to what can be done by metacity.

gconf can fetch config through CORBA!

jeromeg

Member

From: France

Registered: 2010-11-11

Posts: 131

Website

Re: xfconf architecture design goals question

The main advantage of having a daemon which handles the preferences is that it can send signals on property changes which can be "monitored" to update the status of the application on the fly. d-bus is just used as a means of communication between the applications and the configuration daemon.