Architecture for XFce [was: icons for Settings Manager]
benedikt.meurer at unix-ag.uni-siegen.de
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
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 :-)
PS: Sorry for this bad english, but I haven't had enough sleep the last nights.
NetBSD Operating system: http://www.NetBSD.org/
pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/
XFce desktop environment: http://www.xfce.org/
German Unix-AG Association: http://www.unix-ag.org/
OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
More information about the Xfce4-dev