GNUstep and the desktop

[Alexander Malmberg]

Hi,

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

I use desktop environment in a slightly fuzzy sense here, but basically,
I mean a self-contained user environment with some basic level of app
integration (eg. it needs to provide a way for users to start apps, and
basic stuff like copy&paste, and it may include lots more stuff, like a
standard browser and file viewer, sound playing, file type/app mappings,
etc.). GNOME, KDE, and Windows are examples. A system can have more than
one desktop environment running at one time.


GNUstep (-gui) really wants to be a desktop environment. Some parts of
the OpenStep/OPENSTEP interface really only make sense when part of a
desktop environment. Workspace/window/dock handling is part of this, as
is file modification notifications, 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 implementation of these things in -gui will,
basically, suck. Proper implementations require making desktop-level
assumptions, and -gui can't make those assumptions 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". Desktop bundles would live outside -gui, but would
work with -gui to provide an implementation of the "desktop environment"
part of the -gui interface. Applications would be written against this
interface, and would thus work well on any implementation.

I plan on working on one "desktop bundle" implementation for Backbone,
and I hope that others will work on other implementations, ones that
integrate with other desktop existing environments (eg. for GNOME, for
KDE, for Windows, ...), or that work with a new desktop environment (eg.
for Chad's DirectFB desktop, ...).

In many ways, this is similar to the current backend/frontend split in
-gui. -gui provides a rendering interface, but system-specific backends
provide the implementation. It may be tempting to include the desktop
functionality in the backend, but this is the wrong thing to do, not
least because of X's desktop schizophrenia. _If_ all users of a
particular backend can agree on a single desktop to integrate with, we
could look at making a combined backend/desktop bundle (this might 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. Specifically, -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 system/backend-specific features in
their implementation. Likewise, code sharing between 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 implementation 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
implementations, 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. Working through -gui to implement desktop bundle
loading and clean "plugging in" will show which parts, and this will be
clearly documented. It would include large parts of NSWorkspace, parts
of NSApplication, and NSSound.

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 bundles 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 that a bundle can cleanly plug in an implementation (ie. turning
some classes into class clusters, or adding "internal" classes for
desktop bundles to override and 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