On 27 Jan 2006, at 15:47, Enrico Sersale wrote:
On 2006-01-27 16:24:13 +0200 Richard Frith-Macdonald
<[EMAIL PROTECTED]> wrote:
On 26 Jan 2006, at 16:26, Enrico Sersale wrote:
On 2006-01-24 11:15:10 +0200 Chris B. Vetter
<[EMAIL PROTECTED]> wrote:
On 1/24/06, David Ayers <[EMAIL PROTECTED]> wrote:
Enrico Sersale schrieb:
[...]
In other words: I want to re-propose a "workspace" daemon that
implements all the NSWorkspace methods that imply distributed
information, leaving all the other things to the normal
NSWorkspace
instance.
FWIW... I think this approach has a lot of merit.
Uhm, yes, but wouldn't that introduce conflicts with a 'real'
Workspace Manager that is actually *supposed* to offer that
functionality?
--
Chris
Thinking better I've ended with choosing to implement all the
stuff in GWorkspace.
For the moment, I've added -launchedApplications.
I've added a fallback mechanism in NSWorkspace to use the local
filesystem to store appinfo if we have no workspace-manager app/
daemon. I *know* from past experience that windows users in
particular will complain if they can't do things without
launching another daemon, so the fallback mechanism is essential.
Agree.
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.
All this stuff is already on CVS but it's untested because today
I've not had the time for building -gui with a modified NSWorkspace.
I wrote a trivial tool 'gcloseall' to call -launchedApplications then
iterate through the returned array terminating all the applications.
When I ran it without GWorkspace running (so it used the fallback
mechanism) it worked fine.
When I ran it with GWorkspace running, it received an array
containing only the information for Gorm (as long as Gorm was
running) ... but not the information for Ink and GSFractal (which
were also running) or for the second copy of Gorm, so I think it
needs some debugging yet.
Also I noticed that the information I did get (for Gorm) lacked the
application path and process identifier.
Perhaps you could add in NSWorkspace.m a declaration of an informal
protocol to be used only as a reference for who wants to write
other workspace applications/daemons.
Or perhaps just listing the methods in the documentation?
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
