Re: GWorkspace future

[Enrico Sersale]

On 2004-02-04 07:34:58 +0200 Sheldon Gill <sheldon@iinet.net.au> wrote:

> 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've no intention of make it invisible. I wrote that period without thinking...
(for Lars: ok, I'll write the list view :-) )

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

Ok. Then I'll write a protocol to be used for writing bundles that the app will 
load only from, say, $GNUSTEP_USER_ROOT/Library/Desktop.
The tabbed shelf will be a default element (you can anyway remove its bundle). 
This because it simulates transparency between the tabs using a NSImage taken 
from the undelying NSView.

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

This is exactly what actually already happens in the main application; take a 
look in GWorkspace/GWorkspace.m, in 
-performFileOperation:source:destination:files:tag: and in 
GWorkspace/FileOperations/FileOperation.m. In this case the progress windows 
belong to the main threrad, while the operation itself is run in an other 
thread, To put all this stuff in a separate app should not represent a overhead.
The need of a separate app comes from the fact that it is the dnd taget to 
start the operation. And, with the proposed solution, we'll have such objects 
in more of one application; in the file viewer, in the desktop, in the finder, 
etc.

> > - 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)

Again, this feature is part of GWorkspace since years. I wrote the daemon (it 
is already on CVS), because there will be many apps intrested in these 
notifications.

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

Omni-present docks, multiple workspaces, mini-windows. These all are things 
that imply access to the backend/window manager. GWorkspace is only a GNUstep 
application and can't do anything for them. The actual fiend is only a 
surrogate.

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

BTW In my last mail I've written also about an integration of the GWorkspace 
and GWNet viewers but, till now, I've had no report regarding GWNet. Does it 
work? Problems? Bugs? It is a new application (tested only by me) and I can't 
think that it has no problems...