Re: Changes to NSWorkspace

[Enrico Sersale]

On Mon, 26 Nov 2001, Fred Kiefer wrote:

> I did do a lot of changes at NSWorkspace and will continue this work as
> soon, as I am back home again. Although it is still in an intermediate
> state I would like to hear your comments and suggestions. (Especially on
> a way to find out if a drive is removable. I have no idea here)
>
> Most of the changes are just cleanups and improvements, but there is one
> change that will break compatibility for GWorkspace:
> I added some of the class variables to the instance itself. OK, we are
> talking here about a singleton, still I prefer to keep things where they
> belong. So now the method [init] must be called for NSWorkspace, and so
> any subclass not doing so will get problems. Than again a subclass that
> will call it gets problems, as this will return the shared instance.
> The only way out is not to subclass any class that is a singleton, and
> this is a general advice in oo programming.
>
> What do do for GWorkspace? Don't inherit from NSWorkspace, but use one,
> if you need it. I had a quick look at the code, and there aren't many
> places where super methods are called, so this is easy to change and
> will work with every implementation of NSWorkspace. There is one place
> where functionality will be missing: The file operations. Here I want to
> ask Enrico, if he would like to donate his implementation of them to
> GNUstep.
>
> Fred
>

NSWorkspace looks like a particular class. Some of its methods, as, to
make only two examples, [-selectFile:inFileViewerRootedAtPath:] and
[-openFile:fromImage:at:inView:], seem to suppose the existence of a
Workspace Manager application.

I don't know how this thing is organized in the various *step, but, when
I've started to write GWorkspace, I've thought that, subclassing
NSWorkspace would had been the best solution.
This should have allowed me to try to implement all the NSWorkspace's
methods that imply the existence of the Workspace Manager app and that are
not implemented in the library.
I think that, in the actual situation (two back-ends, a window manager,
etc.), it appears as a reasonable compromise...

Anyway, it is not a problem if I can't inherit anymore from NSWorkspace
;-) this is a less important thing; GWorkspace can remain, simply, an app
that use the NSWorkspace shared instance when it is needed and that has
*its* -performFileOperation:etc:etc:etc... method.

The *real* problem, I think, can be explained so:

We should decide if the GNUstep Workspace Manager must remain a simple
application or must be somewhat integrated in the libraries.
The integration, as I'll explain, is not a very easy thing, and I don't
know if it is possible in the actual situation, due of the presence of a
window manager and other things...
I hope that we will not end with a half-implemented class and a broken
application ;-)

1) if we think that it must not be fully integrated, then it is better if
NSWorkspace remains an inheritable class. In this case, all the methods
regarding the Workspace will be implemented in the app(s) with this
function.

2) if we decide for the itegration, keep in mind that this will not be as
easy as it can appear.
The problem is not represented only by methods as performFileOperation,
but by methods as [-selectFile:inFileViewerRootedAtPath:], that imply the
existence of a viewer.

Sure, I can donate the implementation of the file operations, but let me
explain what this would imply:

In the actual implementation of
-performFileOperation:source:destination:files:tag:, a "FileOperation"
object is allocated and added in an array of file operations.

  ops = [[FileOperation alloc] initWithOperation: operation
              source: source destination: destination files: files];
        [bgdOpsArr addObject: ops];
  RELEASE (ops);

This object, at his turn, launches a new task with the "backgrounder" tool
and creates a NSConnection with it.
>From this point, the tool takes the control of the situation and tells the
FileOperation object when it must show alert panels, update the processes
window and notify the viewers of changes in the file system.

This means that you must find a place in the libraries also for the
FileOperation class, the backgrounder tool and the Processes window....

But the Processes window is used also by the running apps list and this
means to add that code too (two or tree classes). These classes, at their
turn, will have some other kind of dependence and so on...

All this only for performFileOperation.

Now if we consider also some methods as
[-selectFile:inFileViewerRootedAtPath:], where the NSWorkspace class must
know of the existence of a viewer, I think that it becomes obvious that,
if we want an integration, only a *full* integration is reasonable.

Anyway, if you decide for this solution, I can collaborate...

I hope my Englisk was sufficient... ;-)

Enrico Sersale

P.S.
Please, can somebody add me to the address@hidden list too?
If Fred Kiefer had not have sent this mail directly to me too, I've had
not seen it...