Architecture for XFce [was: icons for Settings Manager]

Benedikt Meurer benedikt.meurer at
Thu Jan 15 19:28:47 CET 2004

Jasper Huijsmans wrote:
>>That'd mean to implement work-arounds later on to get the new technology 
>>working in the existing framework. Thats IMHO the wrong way.
> Why? The daemon must do everything the xfce modules would use the
> library for, right? It only means you have to be careful to not expose
> implementation details in the API. This is a good thing anyway.

In a perfect world, yes. But from what I have seen so far its usually less 
perfect and ends up with slow and broken code just because everyone tries very 
hard to not break the existing API.

> BTW, I know you prefer beautiful designs, but I'm not sure that will
> ever work in a project like ours. Open source projects evolve in little
> steps, by many different people. No-one gets things right the first
> time. Grand total designs don't fit well with this method of
> development.

My believe is that open source projects are indeed able to create "beautiful 
designs". Imagine the man-power of the developers, I think discussing a 
problem 1-2 months on IRC and mailinglists can led to a quite good design, 
though its harder than the usual design process we are usually involved at work.

 From my point of view, the problem is not that it is not possible in open 
source projects, but that most open source developers tend to sit down at 
their computers, hack some code and hope that it'll run as expected. Once they 
realize that this development model works unexpectedly good for their small 
applications, they start thinking that everything can be done this way (the 
actual advantage of this model is the "fast response", that is the user can 
see the result even in very early stages in the development process). I made 
the same fault when I started with the session manager. My first phase was 
testing and learning, this BTW my beloved development phase, because its 
really just hacking and at the end of that phase you either say "Its 
impossible for that money" or present your "Proof of Concept". The next step 
was design. I did only basic design steps because I underestimated the 
dependencies and some use cases and went on to the actual coding. Now when I 
came back to the session manager a 1/2 year later and wanted to finish the 
points on my TODO list I realized that I forgot some important relationships 
in my analysis and now have to partly redesign to integrate the new functionality.

Anyways, back to topic. I have collected some pieces of information and did a 
basic design of a potential architecture for the system described earlier in 
this thread (I called it "XFce all-in-wonder system" in lack of a good name 
for now) and put it online here:

This is only a first-time-thoughts document, nothing special and nothing 
ready-to-implement. There are some problems with the described approach and 
there are a lot of things open for discussion.

For example, one thing I though of, was to use D-BUS (or even ICE) as the 
Transport Layer. But D-BUS is not yet ready for production use, so here the 
question comes up, when do we need to finish with the new framework to have it 
ready for 4.2?

Any comments/feedback welcome, but please focus on the topic and no comments 
like "I don't like that" or sth like that, instead write "I don't like that, 
because ... and we could improve it by ..." (of course you can also write 
comments like "I like that..." :-).

> I'd be happy to be proven wrong, but I'm not hopeful,

I think we can manage to prove you wrong :-)

> 	Jasper


PS: Sorry for this bad english, but I haven't had enough sleep the last nights.

NetBSD Operating system:             
pkgsrc "Work in progress":        
XFce desktop environment:              
German Unix-AG Association:         

OpenPGP Key:

More information about the Xfce4-dev mailing list