Goals of Xfce (long)

[Edscott Wilson Garcia]

Hola Jasper,

Some comments:

El vie, 03-06-2005 a las 13:24 +0200, Jasper Huijsmans escribió:
> 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).
> 

A typical user will user his/her computer for listening to music,
watching movies, surfing the web, writing email, editing text documents,
spreadsheets, drawings, these are applications. The desktop environment
should be there to help the user achieve these goals with a minimum of
effort, maximum speed and minimum use of system resources (which by
birthright belong to the applications).

This is something the big 2 seem to ignore. The desktop environment is
the means, not the end. 

Thus, goals 1) and 2) are paramount. Goals 3), 4) and 5) are commendable
and should be strived for insofar as they do not interfere with 1) and
2).

> ===
> 
> 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.

Right, very logical. But only insofar as goals 1) and 2) are not
comprimised. Why do I say this? Linking a 200 line program with a 10000
line library may not always be wise (sometimes it might, there is no
substitute for common sense). The OS will only load one copy of a given
library and thus the most probable situation is that the panel will
already have mapped the library. But if the panel is not constantly
using the symbols defined by the library (which is typically the case),
the library is swapped off to hard disk. Thus, after a period of
inactivity, the library will have to be read from disk again and
remapped. Simple desktop functions should not make the user wonder why
it is taking so long.


> 
> ===
> 
> 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.
> 

Rox is a desktop environment centered around a filemanager. Xfce has
always been based around the panel (aided by small tools like xfdestop
and xftaskbar and xfrun). The rest is up to the user. Of course we
should provide Xfce alternative(s) to components considered core in
other desktops, such as the file/window/session manager. Insofar, at the
risk of being repetitive, as goals 1) and 2) are not comprimised.
But since both Nautilus and Konqueror are extremely good programs and
many users will opt for one of those anyway, it is good to give the user
more choices. 

On the Gnome issue, I don't think it would be a good idea to jump on the
Gnome dependency train, unless a goal further down the line is to be
included in the big G and eventually land a job at Novell Inc. If this
is the case, whoever already has the job will always be one step ahead,
until he goes off to work at MS Inc.


> ===
> 
> 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.

Very good post, Jasper. Well written and thought out.

regards,


-- 
Edscott Wilson Garcia <edscott at xfce.org>