Goals of Xfce (long)

Jasper Huijsmans jasper at xfce.org
Fri Jun 3 13:24:03 CEST 2005


Benedikt recently said he wasn't sure what the goals for Xfce were, and maybe
he isn't the only one. This post is an attempt to explain my ideas about it. I 
have to warn you though, it is long ;)

To try and explain what I feel is (or should be) the philosophy of Xfce I
tried to come up with a list of goals, not necessarily in order of importance.

1) Useable on older/lower-powered machines. This means try to be fast and
   reduce memory consumption. Even though it may seem obvious, it is important
   to keep in mind that this is probably the main reason for people to use
   Xfce. It is what defines us and makes us an alternative to the big two.

2) Easy to use and visually appealing. No hand-editing of config files should 
   be required for core functionality. Within the limits of goal (1) we should
   try and provide a visually appealing user interface. 

   Note: 'visually appealing' is a very subjective term. For me it means
   simple, straightforward and consistent. Since Xfce is based on GTK+ and 
   many GTK+ apps are written for GNOME, it makes sense for use to use the 
   GNOME HIG as an important guideline. 

3) Modular and robust. If possible (and practical) separate functionality
   should be provided by separate programs. This make interfaces and
   communication between these different parts vital for an integrated desktop
   environment. The idea is to follow the UNIX philosophy of writing tools
   that do one task and do it well.

   Robust, IMO, also requires a limited scope and limited configurability.
   It is usually better to choose a 'good enough for most' behaviour than to
   provide multiple alternative behaviours. This is also needed to give a 
   program its own 'identity', instead of emulating every possible alternative 
   out there.

4) Standards-compliant. The goal should not be to support as many standards as
   possible, but when Xfce provides functionality for which there is a
   relevant standard we should try and support that standard. Especially
   important in this case are standards for interoperability with other
   desktop environments, such as those provided on freedesktop.org .

5) State-of-the-art. To provide our users with a modern desktop environment it
   is important to pay attention to and make use of new technologies for X11
   when they become available (and are mature enough). A good example is the 
   support for transparency and window shadows by using the new XOrg composite 
   extension (optional and non-default, because of the lack of maturity).

===

Ok, so that's (some of) the goals, now on to the implementation.

Integration between Xfce components, as well as consistency within the desktop
environment can be achieved by using the development platform. To decide
what should be in our libraries, let's try to put up a set of guidelines.

1) Shared implementation. Functionality used by more than one or two Xfce
   components should be in a library.

2) Implementation of (freedesktop) standards. The platform should provide an
   easy way to make use of interoperability standards. Different
   implementations of a standard within Xfce will hurt the consistency.

3) Special Xfce user interface elements. The platform should promote a
   distinct style for Xfce by providing standard widgets and dialogs to be
   used by all components.

4) Backporting glib/gtk stuff. Because we tend to not require the latest gtk
   version, there may be situations where we need to implement functionaility
   already present in the latest gtk release; in that situation we should try
   to create small wrappers that call the new gtk functions if available and
   implement them (copy+paste or implement new API using old functions) for
   older gtk versions. In general we should avoid duplicating functionality
   available in gtk.

===

As you may have noticed, I deliberately didn't touch the most difficult
questions: what should be part of Xfce and what functionality do we want to 
provide? I guess this is still, and will always be, open to debate.

I think we can devide a desktop system running Xfce into different layers:

1) Platform: basic system libraries, glib/gtk, Xfce libraries.

2) Desktop
   a) core programs: xfwm, xfdesktop, panel, xfce4-session
   b) essential scripts/utilities: startxfce4, etc

3) System tools
   a) utilities: calendar
   b) panel plugins
   c) file manager(s)

   Note: most desktop environments consider a file manager part of (2). It is
   not so currently for Xfce, but perhaps we are wrong.

4) User programs
   a) Based on the Xfce platform, e.g mousepad
   b) Third-party: firefox, OOo, GNOME/KDE apps, ...

So, the difficulty about what to include with Xfce is in layer (3). I believe 
some things can be separate projects (file manager, plugins) and some things 
can be part of Xfce (calendar), decided on a case-by-case basis.

Another area we may want to re-evaluate every now and then is the dependencies. 
This is layer (1), which at the moment consists basically of gtk+ and libxml. 
Again we could look at the GNOME platform to see if it make sense to use
some of their facilities instead of writing our own. A possible example
is using gnome-vfs instead of using our own file operations library, or using 
GConf for our configuration. The problem here often is that we'd have to pull 
in the entire GNOME platform, including bonobo.

===

So, wow, you read until here. Thanks ;-) Not sure this was very useful, but it
was good to try and write down my ideas about Xfce. Most of the time we are
only dealing with implementation details, but it doesn't hurt to look at the
big picture sometimes.

Another thing I feel is that the project is becoming rather big, and we reach
the limits of what our developer group can handle. Finding new developers and
getting better at accepting help from other people, making it easier to
contribute, will be important for Xfce. Ideas or suggestions about this are
very welcome.

	Jasper



More information about the Xfce4-dev mailing list