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