[Gnustep-cvs] gnustep/core/gui/Tools gcloseall.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald [EMAIL PROTECTED] 06/01/27 18:13:46 Modified files: core/gui/Tools : gcloseall.m Log message: Fix possible problem iterating array of apps CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Tools/gcloseall.m.diff?tr1=1.1tr2=1.2r1=textr2=text
[Gnustep-cvs] gnustep/usr-apps/gworkspace/GWorkspace GWorkspa...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Enrico Sersale [EMAIL PROTECTED] 06/01/27 13:15:43 Modified files: usr-apps/gworkspace/GWorkspace: GWorkspace.h GWorkspace.m WorkspaceApplication.m usr-apps/gworkspace/GWorkspace/Desktop/Dock: Dock.m Log message: CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/GWorkspace.h.diff?tr1=1.63tr2=1.64r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/GWorkspace.m.diff?tr1=1.115tr2=1.116r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/WorkspaceApplication.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/Desktop/Dock/Dock.m.diff?tr1=1.12tr2=1.13r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSApplication...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald [EMAIL PROTECTED] 06/01/27 12:44:01 Modified files: core/gui : ChangeLog core/gui/Source: NSApplication.m NSWorkspace.m Log message: Updates for keeping track of launched/active applications when there is no workspace manager process. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2646tr2=1.2647r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSApplication.m.diff?tr1=1.287tr2=1.288r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSWorkspace.m.diff?tr1=1.89tr2=1.90r1=textr2=text
Re: Graceful termination again
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]. 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. These will be fixed in the next days, using also the new NSApplication notifications. (hoping that the tomorrow SVN switch will not give too much problems...) 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
Re: Graceful termination again
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 _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. 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? 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. 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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui/Source NSApplication.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald [EMAIL PROTECTED] 06/01/28 21:00:30 Modified files: core/gui/Source: NSApplication.m Log message: fix typoCVS: -- CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSApplication.m.diff?tr1=1.288tr2=1.289r1=textr2=text
