On 27 Jan 2006, at 22:40, Enrico Sersale wrote:
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.
Ah ... that seemed the obvious way to do things to me ... but perhaps
not the way other people would do it. In any case, it's certainly a
*possible* way to implement things, so I think we do need to be able
to handle that situation.
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.
OK ... I think this means I have no further actions to take on this
until/unless you let me know of any bugs you find in the NSWorkspace
class.
If I'm wrong, please let me know.
Once we are confident that we have a good solution, I'll add some
documentation for it, and perhaps a tiny example implementation of a
workspace manager daemon.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
