Re: A little help for GWorkspace

[Enrico Sersale]

On Fri, 12 Jan 2001, Philippe C.D. Robert wrote:

> "Pascal J. Bourguignon" <pjb@imaginet.fr> wrote (Fri, 12 Jan 2001 02:33:03 
> +0100 (CET)):
> > By the way, one thing I did not like is that it was possible to delete
> > items  while  they were  on  the  shelf.  For example,  the  following
> > sequence that I intuitively did, and lead to problems:
> >     
> >     - move /a/b/c on the shelf.
> >     - delete /a/b (with command-r, unfortunately),
> >     - move the c on the shelf to /x/y, but what? no more c exists!?
> > 
> > Well, ok,  once I lost some precious  files, I took care,  but the bad
> > lesson learned was that the shelf was not to be trusted... I would not
> > mind if GWorkspace behaved differently here.
> 
> Hmm... I think it is not bad to be allowed to delete/remove files/directories 
> when they are on the shelf. As far as I remember, NEXTSTEP removed 
> nonexisting files from the shelf - at least when updating the browser (if 
> GWorkspace does that more often than the original, I don't seea major problem 
> there).
>  
> cheers, Phil

In GWorkspace, all the updates of the browser's columns and of the shelf,
are notification-drived.

When you DnD something and start a file operation, (in this exemple a
NSWorkspaceMoveOperation) you are calling the NSWorkspace
__performFileOperation_source_destination_files_tag_ method.

The GWorkspace's main class, GWorkspace, is subclass of NSWorkspace and,
in its implementation, this method simply create an object of type
"FileOperation", put it in an array, release it and return YES.

The new FileOperation object starts an istance of the "backgrounder" tool
and send immediately a "FileSystemWillChangeNotification" (note: *Will*)
that has, as object, a dicionary with the operation name, the souce path,
the destination path and an array with the file names involved.

The Viever and the Shelf are waiting for this notification.

The Viewer, in __fileSystemWillChange_ , add some dimmed (grey, not
selectable) cells with the files names in the browser column with
path=destination.
If a column with path=source also exists, the cells corresponding to the
file names are removed.

In the Shelf, __fileSystemWillChange_ verifies if there is an object whith
a path equal to one of the files or deeper, and remove it. 
So, if you have /a/b/c and move b, c will be removed too. 

When the operation ends, successfully or not, the FileOperation object
will send a GWFileSystemDidChangeNotification (note: *Did*) with the same
contents.

Now, in __fileSystemDidChange_ , the Viewer empties the source and the
destination columns to remove the provvisionals cells and reload their
contents to assicure a correspondence with the actual situation. 

Regarding NSWorkspaceCopyOperation, NSWorkspaceLinkOperation,
NSWorkspaceDestroyOperation and NSWorkspaceDuplicateOperation, the
behaviour can change a little, but, basically, this is as it works.

  Ciao,
   Enrico