Fred Kiefer wrote:
[snip]
I can almost fully support your practical proposals, which are not to
far away from GNUsteps current implementation:
NSWorkspace already delegates most of its operations to a well defined
interface for a workspace application.
Which isn't appropriate if you don't control the workspace application,
like on windows or GNOME. A pure GNUstep desktop bundle might choose to
implement it this way, but I don't think -gui should make assumptions
like that.
Still there a few more methods
that need implementation and are best left to an external application.
NSSound is rather similar, it interfaces with a sound deamon, all we
have to do, is to move this deamon out of GUI to a separate module.
Same issue. There's no sound daemon on windows, so NSSound there should
use native facilities to play sounds; GNOME has its own sound
management, and seems to be using esd, so NSSound there should use that.
Again, -gui is not the place to make assumptions about how these things
should be implemented.
But
we will still need to provide this deamon in the future.
As for NSApplication, I am not sure which interfaces you are refering
to. The only methods, that spring to my mind are unhideAllApplications:
and hideOtherApplications:, both of which could be implemented via the
service provider and its connection to all other GNUstep applications.
Not all applications are GNUstep applications. -gui can't hide the
non-GNUstep apps; desktop bundles can.
To me, it sounds like you want a pure GNUstep desktop, OPENSTEP-style.
That's great! However, I don't think that should block work that others
want to do to use GNUstep as a part of other desktops. My proposal would
make it possible for you to work on your desktop, together with others
who share the same goal, without interfering with (or being interefered
with by) others with different goals. :)