Re: GWorkspace future

[Sheldon Gill]

On Tue, 3 Feb 2004 21:25, Enrico Sersale wrote:
> I would to split GWorkspace in some applications.
> Please, let me know what you think about this.

I think this is absolutely the right way to go.

> - Desktop:
> The actual desktop window, the tabbed shelf and a trash.
> Already having the shelfs of the viewers, the tabbed shelf and the fiend,
> the desktop would represent a place in the file system (probably
> $GNUSTEP_USER_ROOT/.Desktop).

I would think "Desktop" rather than ".Desktop".  Having it browsable is a good 
thing and I can see no reason to inhibit that. Where desktop databases and 
additional meta-information go is probably a separate thread...

I'd suggest it's better to separate the "Desktop" from shelf/fiend/dock 
entirely. That way it's easier to experiment with different implementations 
of those elements which the desktop layer remains.

> - Operation:
> The app that performs the file operations ans shows their progress.

Again, the right approach. I would think, though, that we'd need to develop 
some reasonably clever architecture to do this well. If the operation is 
quick then the overhead of creating a new process, opening a new windows and 
trying to display progress will slow things unacceptably.

> - fswatcher:

This is basically fam integration. Do we need a separate daemon to wrap it? 
Given the other Workspace notifications we're interested in I'm thinking that 
it's best done within the "main" app, probably the one responsible for the 
desktop itself as it'll need to receive such information and add to it (icon 
changes, labelling, mounting/unmounting and so on)

FIEND, SHELF AND DOCK
=================

I think that the "fiend/miniwindow" as we have it shouldn't be part of 
gnustep-gui but rather a feature of the workspace in which the application 
runs.

I believe it should be the responsibility of the <desktop environment> to 
display the mini-window/fiend in a way appropriate for it.

The current situation is that the backend is responsible for deciding if 
miniwindows should be handled by the application itself.  So it's all or 
nothing for a particular display server.  It's enabled for X, so you get 
miniwindows under all window managers. I think it's time it became a separate 
thing so those using (eg. Window Maker) can have the same old but those using 
different desktops can have something more appropriate.

All the miniwindow handling is dead code for Windows. We can clean things up. 

There's another reason, here, too.
One long term goal for GNUstep is flexible themes.  This is going to be an 
issue for applications which direct changes to their mini-window. Planning 
the architecture now is probably the right time as you're looking at the 
whole picture.


Regards,
Sheldon