On 2006-01-27 23:07:30 +0200 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote:
On 27 Jan 2006, at 20:10, Enrico Sersale wrote:
On 2006-01-27 20:14:40 +0200 Richard Frith-Macdonald
<[EMAIL PROTECTED]> wrote:
On 27 Jan 2006, at 15:47, Enrico Sersale wrote:
[snip]
I still think it would be good to get round to implementing the
capability of asking the workspace manager to perform operations
centrally, but we need to think about defining the api/protocol that
NSWorkspace should use to talk to it.
I don't see any reason why we need to design the whole thing at once
though. We could just add methods as we want to implement them.
What do you think are the most important operations that should be
handled centrally?
There are not many operations.
Besides -performFileOperation::::: and -
selectFile:inFileViewerRootedAtPath: that are already performed in the
workspace application, I've implemented the following methods that seem
to cover all the needed operations:
-openFile:withApplication:andDeactivate:
(in NSWorkspace this is called also by:
-openFile:withApplication:
-openFile:
-openFile:fromImage:at:inView:)
-launchApplication:showIcon:autolaunch:
(in NSWorkspace this is called also by:
-launchApplication:)
-openTempFile:
-_launchApplication:arguments:
-launchedApplications
I've also -extendPowerOffBy: but, for the moment, it does nothing.
I've made sure that all those (with the exception of the private
_launchApplication:arguments: method) try to ask the workspace manager
for the information.
I also made -activeApplication query the workspace manager.
There is only a little problem:
NSWorkspace, in -_workspaceApplication, if its instance has been created
by the the workspace application itself, returns nil; but there are many
places in GWorkspace where [NSWorkspace sharedWorkspace] is used for
icons, for methods as - getInfoForFile:application:type: but also for
launching an application or for opening files. With the current
implementation I should change [NSWorkspace sharedWorkspace] with
[GWorkspace gworkspace] in tens of places. Moreover, GWorkspace is made by
various frameworks, bundles and classes where the GWorkspace class is not
visible.
What do you think about adding to the workspace application "protocol" a
"+sharedInstance" class method to be called in - _workspaceApplication?
With this solution -_workspaceApplication would return the local instance,
avoiding any recursion.
Something like [[[NSBundle mainBundle] principalClass] sharedInstance].
I'm pretty sure I don't understand.
The misunderstanding comes from the fact that I was not tinking that you
suppose that the remote object returned by -_workspaceApplication is an istance
of a NSWorkspace subclass.
The _workspaceApplication method is a private method to return a proxy to
the remote workspace application ... with the idea being that NSWorkspace
methods will call it to get the remote application ... and either use that
remote application to do a job or, as a fallback mechanism when there is no
remote application, do the job themselves. If the method returns the local
instance of NSWorkspace, you get recursion.
Now this this is clear.
I *think* you may be saying that in GWorkspace works by, instead of
subclassing NSWorkspace and overriding methods, expecting
_workspaceApplication to be returning a proxy to another object in the
application which implements the same methods?
Yes.
If that's the case, probably the best thing to do would be to override
_workspaceApplication (eg in a category) to return the object you want it to
return.
This would work but I think that I'll make GWorkspace a subclass of NSWorkspace.
If we think other apps need to do that, I guess we should rename the method
and make it public (possibly the effect you intend when suggesting adding a
'+sharedInstance' method). However, I would have thought that the intuitive
way to implement different behaviors in NSWorkspace would be to subclass it
and use a category to override +sharedWorkspace and -init to return an
instance of the subclass.
But perhaps I'm missing the point entirely ...
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
