Hi,

This discussion (finally) prompted me to finish writing this thing (has been sit
ting here as an incomplete draft for a while).

GNUstep (-gui) really wants to be a desktop environment. Some parts of the OpenS
tep/OPENSTEP interface really only makes sense when part of a desktop environmen
t. Workspace/window/dock handling is part of this, as is file modification notif
ications, sound playing, running application lists, and many other things.

However, -gui can't be a desktop environment because this runs contrary to other
 basic goals in GNUstep (desktop environment agnosticism and portability). Any i
mplementation of these things in -gui will, basically, suck. Proper implementati
ons require making desktop-level assumptions, and -gui can't make those assumpti
ons because it needs to run "everywhere".


My proposed solution to this conflict is to explicitly turn -gui into a desktop 
environment _interface_, and to move the implementation to "desktop bundles". De
sktop bundles would live outside -gui, but would work with -gui to provide an im
plementation of the "desktop environment" part of the -gui interface. Applicatio
ns would be written against this interface, and would thus work well on any impl
ementation.

I plan on working on one "desktop bundle" implementation for Backbone, and I hop
e/expect others to work on implementations that integrate with other desktop env
ironments (eg. for GNOME, for KDE, for Windows, for a DirectFB desktop, etc..).

In many ways, this is similar to the current backend/frontend split in -gui. -gu
i provides a rendering interface, but system-specific backends provide the imple
mentation. It may be tempting to include the desktop functionality in the backen
d, but this is the wrong thing to do, not least because of X's desktop schizophr
enia. _If_ all users of a particular backend can agree on a single desktop to in
tegrate with, we could look at making a combined backend/desktop bundle (this mi
ght be applicable in the win32 case, although prior discussion implies that the 
_if_ doesn't hold).

Note that the implementation of desktop bundles is outside the scope of -gui. Sp
ecifically, -gui won't provide any special means of actually implementing them (
just for plugging in the implementations). However, desktop bundles can be (and 
are meant to be) as system/backend-specific as they need to be, and can use syst
em/backend-specific features in their implementation. Likewise, code sharing bet
ween desktop bundles is outside the scope of -gui (like back/gsc/).


So, to sum up the abstract -gui side of things:

-gui will provide a desktop environment interface.

-gui will provide a dummy "standalone" implementation of this interface. This im
plementation will be portable and sufficient to run (correct) apps, but it won't
 provide any actual desktop or inter-app integration.

-gui will be arranged so that desktop bundles can easily plug in other implement
ations, and it will provide a means of loading a user-specified desktop bundle.


And, more practically:

The interface will, at first, be the "desktop parts" of OPENSTEP/OpenStep. Worki
ng through -gui to implement desktop bundle loading and clean "plugging in" will
 show which parts, and this will be clearly documented.

Extensions will likely be necessary, but not until things have stabilized. As a 
guideline, I'd say that an extension should be implemented in two desktop bundle
s and used in two apps before it's "formalized" in GNUstep-gui's interface.

There'll be a bunch of work necessary in -gui. Mostly rearranging the -gui so th
at a bundle can cleanly plug in an implementation (ie. turning some classes into
 class clusters, or adding "internal" classes for desktop bundles to override an
d using them in the public classes). This will also involve moving some code out
 of -gui (eg. gsnd; some (most?) existing desktop environments already have some
 sound system).

Thoughts?

- Alexander Malmberg