Re: what to do now? (was: Re: Graceful termination again)
On 2006-02-05 18:00:01 +0200 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 5 Feb 2006, at 12:17, Enrico Sersale wrote: But now my problem is how to implement all the "graceful termination" stuff; I suppose that I should add a "Logout" menu and send a NSWorkspaceWillPowerOffNotification through the NSWorkspace notification center; I don't think that's necessary ... you can just send a -terminate message to the application, and the app will generate an NSWorkspaceWillPowerOffNotification internally. but, unlike NSApplicationWillTerminateNotification, for NSWorkspaceWillPowerOffNotification you must explicitly add your application delegate as a observer of this notification; this means that *all* the actually existing GNUstep applications will not work... Well . they probably won't observe the NSWorkspaceWillPowerOffNotification and won't call - extendPowerOffBy: ... but they should terminate properly. I think apps probably only need to observe NSWorkspaceWillPowerOffNotification is they expect their shutdown process to take a relatively long time and want to ask for enough time to do it cleanly (eg they need to save a lot of state information to disk). Moreover, I can't find any Apple documentation about this. Last question: which is the role of -extendPowerOffBy: in all this mechanism? I *think* the shutdown sequence should go like this ... 1. GWorkspace sends a -terminate to the applications. 2. GWorkspace waits some set time for applications to actually terminate. 3. After the timeout expires for an app, GWorkspace prompts the user to ask whether the app should be killed forcibly, and then either kills the app or abandons the shutdown process. I've implemented the logout mechanism following these rules. It's on svn. If somebody notices bugs, please report them. The -extendPowerOfBy: mechanism should allow the application to extend the timeout before GWorkspace forcibly kills it. I would suggest that GWorkspace automatically grants moderate extensions (eg up to 30 seconds) and either denies very long extension requests or, asks user about it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: what to do now? (was: Re: Graceful termination again)
On 5 Feb 2006, at 12:17, Enrico Sersale wrote: But now my problem is how to implement all the "graceful termination" stuff; I suppose that I should add a "Logout" menu and send a NSWorkspaceWillPowerOffNotification through the NSWorkspace notification center; I don't think that's necessary ... you can just send a -terminate message to the application, and the app will generate an NSWorkspaceWillPowerOffNotification internally. but, unlike NSApplicationWillTerminateNotification, for NSWorkspaceWillPowerOffNotification you must explicitly add your application delegate as a observer of this notification; this means that *all* the actually existing GNUstep applications will not work... Well . they probably won't observe the NSWorkspaceWillPowerOffNotification and won't call - extendPowerOffBy: ... but they should terminate properly. I think apps probably only need to observe NSWorkspaceWillPowerOffNotification is they expect their shutdown process to take a relatively long time and want to ask for enough time to do it cleanly (eg they need to save a lot of state information to disk). Moreover, I can't find any Apple documentation about this. Last question: which is the role of -extendPowerOffBy: in all this mechanism? I *think* the shutdown sequence should go like this ... 1. GWorkspace sends a -terminate to the applications. 2. GWorkspace waits some set time for applications to actually terminate. 3. After the timeout expires for an app, GWorkspace prompts the user to ask whether the app should be killed forcibly, and then either kills the app or abandons the shutdown process. The -extendPowerOfBy: mechanism should allow the application to extend the timeout before GWorkspace forcibly kills it. I would suggest that GWorkspace automatically grants moderate extensions (eg up to 30 seconds) and either denies very long extension requests or, asks user about it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
what to do now? (was: Re: Graceful termination again)
GWorkspace, if used in the role of NSWorkspace "workspace application" can now return in -launchedApplications the list of all the running apps. As a side effect of this and of all the work that Richard has done in NSWorkspace, NSApplication, etc.., we have now also a working implementation of -hideOtherApplications: and -unhideAllApplications:. But now my problem is how to implement all the "graceful termination" stuff; I suppose that I should add a "Logout" menu and send a NSWorkspaceWillPowerOffNotification through the NSWorkspace notification center; but, unlike NSApplicationWillTerminateNotification, for NSWorkspaceWillPowerOffNotification you must explicitly add your application delegate as a observer of this notification; this means that *all* the actually existing GNUstep applications will not work... Moreover, I can't find any Apple documentation about this. Last question: which is the role of -extendPowerOffBy: in all this mechanism? ___ 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 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
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
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 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 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. 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? ___ 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 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
Re: Graceful termination again
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. 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. 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 24 Jan 2006, at 09:15, Chris B. Vetter 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? No need for it to be that way ... the idea in NSWorkspace is to have the workspace manager it contacts be configurable (in the user defaults system). That's very flexible ... for instance if apps are configured to contact GWorkspace, then GWorkspace could be configured to contact a default daemon to perform operations or it could perform the operations internally itsself, and it would make no difference to the apps using the workspace functionality via the NSWorkspace class. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 2006-01-23 12:54:01 +0200 Chris B. Vetter <[EMAIL PROTECTED]> wrote: On 1/23/06, Roman Belenov <[EMAIL PROTECTED]> wrote: I hacked a bit trying to implement logoff with graceful application termination on GNUstep and got some questions: [...] The way I see it would be sending a NSWorkspaceWillPowerOffNotification when "Logout" (or similar) is clicked to the Workspace / Desktop / Window Manager. The Manager would then use -launchedApplications to send each application a terminate message. Problem is that there currently is no 'real' GNUstep-based XY Manager that implements the above. This could be "fixed" if (for example) GWorkspace could also act as a window manager, to replace the 'need' of Window Maker. -- Chris Having GWorkspace acting also as a window manager would mean too much work :-) But you are right when you say that a "logout" notification should come from the window manager; at http://www.gnustep.it/enrico/wmaker.tar.gz there is a hacked WindowMaker that builds as a GNUstep application; wmaker.tar.gz contains the "src" directory of WindowMaker 0.92 with a GNUmakefile and two added files, WMApp.h and WMApp.m. In WMApp.m there is the implementation of a very simple class that, in -applicationWillFinishLaunching: adds the file descriptor returned by XConnectionNumber() to the run loop and, in receivedEvent, sends the XEvent to the normal WindowMaker function. Nothing else. But, being a real application, WMaker.app could send notifications, communicate with other apps, etc.. This is only an experiment but, if somebody would be interested in working at it, I think that WMaker.app could become the GNUstep window manager. This is a project that should not be very difficult to maintain; if, for the moment, we want only to send some notifications, the work should consist only in writing a better configure script and, when a new WindowMaker will be released, updating our sources (that are only a little part of all the WindowMaker sources, I want to remember). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
Enrico Sersale schrieb: > Perhaps some of the older gnusteppers remember this: > > "The Zen of no UI > Why don't we just write a GNU-DO based WorkspaceMaster which could > perform all the necessary tasks like copying files, killing apps, > checking for removable media etc. pp. and then just use the NSWorkspace > class plus some new notifications to handle the workspace task?" > > 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. > With this solution, the need of the _workspaceApplication method would > remain, but only for those (one or two) methods that require user > interaction for confirmation or in case of error as > -performFileOperation:. The daemon could anyway have a default > implementation that, or does nothing, or perform the operation without > asking the user. > > Moreover, I think that it can be written very easily copying from the > gdnc and GWorkspace sources. FWIW... I think this approach has a lot of merit. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 2006-01-23 15:05:41 +0200 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 23 Jan 2006, at 08:50, Roman Belenov wrote: I hacked a bit trying to implement logoff with graceful application termination on GNUstep and got some questions: 1) How to get a list of all running GNUstep applications ? launchedApplications seems to return only the list of apps launched from the current one. For now I just use a list of message ports obtained by examining corresponding subdirectory and treat everythying as a proxy for application. Well, the way workspace operations generally *should* work as I understand it, is that they should contact the workspace manager application and ask it to do the job for them. There is partial support for this in the NSWorkspace class, but it has never been completed. Basically, the idea is that the local NSWorkspace instance should first try to ask the workspace manager application to do jobs, and if no application is found, it should do the best it can. In the case of launched tasks, this means that every application keeps track of any tasks it sees being launched, but since there is no workspace application launching all tasks, there is no central repository of all the information. So, what you should ideally be doing is fixing that ... Problem is that it was never completed because to make it useful there needs to be a workspace manager application and when I wrote it no such application existed. Then later Enrico wrote GWorkspace without much attention to integration with the NSWorkspace class, and we never got together to make it all work. I've always thought that the NSWorkspace class *implies* the existence of a Workspace application; it is sufficient to read some method declarations to understand this. (and, probably, it implies also the fact that the Workspace application coincides with the "window manager"...). For this reason, I have had already proposed an "integration" of GWorkspace with the NSWorkspace class five or six years ago but my app was just at its beginning (and very buggy) and I received a big NO from the GNUstep mainteners :-) After some years the _workspaceApplication method has been added to NSWorkspace with GWorkspace as default but, in the meantime, GWorkspace had gone its way without (mea culpa) too much attention for the NSWorkspace class; only some of the methods that NSWorkspace could use have been implemented; for example: -selectFile:inFileViewerRootedAtPath: exists but _launchApplication:arguments: doesn't. That being said, I can implement in GWorkspace all we want, if we think that this is the right way, but I'd want to propose something else. Perhaps some of the older gnusteppers remember this: "The Zen of no UI Why don't we just write a GNU-DO based WorkspaceMaster which could perform all the necessary tasks like copying files, killing apps, checking for removable media etc. pp. and then just use the NSWorkspace class plus some new notifications to handle the workspace task?" 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. With this solution, the need of the _workspaceApplication method would remain, but only for those (one or two) methods that require user interaction for confirmation or in case of error as -performFileOperation:. The daemon could anyway have a default implementation that, or does nothing, or perform the operation without asking the user. Moreover, I think that it can be written very easily copying from the gdnc and GWorkspace sources. 2) What is the correct way to check the result of sending terminate to application (from another one) ? Experiments show that if application actually terminates, I get an exception caused by connection timeout. Yes .. you expect the connection to go away when the app terminates. I don't think there is any realistic way you can be absolutely sure an app has completely gone away (though you could try registering a port using the name of the task ... if it works then the app has gone ... if it fails either the app is still running or another app with the same name has started). It's probably best to just assume that loss of the connection to the app means that it has died. Of course, in the case of the workspace manager application (which should generally have launched the app and be responsible for shutting it down too), you have an NSTask object corresponding to the launched application, so you can check the NSTask instance to see if the application is still running after it has been told to terminate. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep
Re: Graceful termination again
Richard Frith-Macdonald wrote: On 23 Jan 2006, at 21:36, David Ayers wrote: Richard Frith-Macdonald schrieb: We could finish getting the NSWorkspace class to do what it was originally designed to do ... provide the list of launched apps as supplied by the workspace manager. That would be a small modification to NSWorkspace and to GWorkspace. However, we would want some fallback option for if/when GWorkspace is not running. Perhaps a minimal workspace manager daemon, or perhaps NSWorkspace could write to a small database (eg a plist file in a temporary directory) to maintain the state information. The latter has the advantages of not requiring an additional daemon to run (I have no problem with daemons, but I know many people have objections to them) and is persistent if the workspace manager is restarted (we need that). The former has the advantages that it would provide a testbed and reference implementation for workspace managers. I suppose we could do both. For what its worth, I think the current approach within -core is right. Minimal NSWorkspace. Keep it lean. The functionality should be implemented by the desktop shell. That'd be: - GWorkspace/WindowMaker for most - For KDE, there'll need to be a different implementation - Win32 needs to talk to the Shell (Explorer) For KDE & Win32 there is no need for another daemon as there already is one running. I'm pretty sure there is a GNOMEish solution, too. I could very well be missing something obvious but I seems to me that gdnc would be a good candidate to provide this service. If we want to put the functionality into an existing daemon, I think gpbs would be the best option, as it is part of the gui/back libraries (ie related to applications) while gdnc provides a service for the base library. I really think the functionality shouldn't be incorporated into either daemon but left for a real NSWorkspace implementation appropriate for the particular running desktop. However, if we want to provide a reference implementation that developers of workspace managers can look at, I think a standalone process would be better than attaching the functionality to an existing daemon... and if we don't want to do that, my preference would be not to bother at all ... just use an on-disk database of the information we need, and modify GWorkspace as our standard workspace manager. A reference/sample implementation is definitely a good idea. I also agree that modifying GWorkspace is the right way... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
--- Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > If we want to put the functionality into an existing > daemon, I think > gpbs would be the best option, as it is part of the > gui/back > libraries (ie related to applications) while gdnc > provides a service > for the base library. > > However, if we want to provide a reference > implementation that > developers of workspace managers can look at, I > think a standalone > process would be better than attaching the > functionality to an > existing daemon... fwiw i sent such a daemon a while ago... http://lists.gnu.org/archive/html/discuss-gnustep/2003-05/msg00269.html thread continues here... http://lists.gnu.org/archive/html/bug-gnustep/2003-06/msg00030.html > and if we don't want to do that, > my preference > would be not to bother at all ... just use an > on-disk database of > the information we need, and modify GWorkspace as > our standard > workspace manager. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 23 Jan 2006, at 21:36, David Ayers wrote: Richard Frith-Macdonald schrieb: We could finish getting the NSWorkspace class to do what it was originally designed to do ... provide the list of launched apps as supplied by the workspace manager. That would be a small modification to NSWorkspace and to GWorkspace. However, we would want some fallback option for if/when GWorkspace is not running. Perhaps a minimal workspace manager daemon, or perhaps NSWorkspace could write to a small database (eg a plist file in a temporary directory) to maintain the state information. The latter has the advantages of not requiring an additional daemon to run (I have no problem with daemons, but I know many people have objections to them) and is persistent if the workspace manager is restarted (we need that). The former has the advantages that it would provide a testbed and reference implementation for workspace managers. I suppose we could do both. I could very well be missing something obvious but I seems to me that gdnc would be a good candidate to provide this service. If we want to put the functionality into an existing daemon, I think gpbs would be the best option, as it is part of the gui/back libraries (ie related to applications) while gdnc provides a service for the base library. However, if we want to provide a reference implementation that developers of workspace managers can look at, I think a standalone process would be better than attaching the functionality to an existing daemon... and if we don't want to do that, my preference would be not to bother at all ... just use an on-disk database of the information we need, and modify GWorkspace as our standard workspace manager. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
Richard Frith-Macdonald schrieb: > > We could finish getting the NSWorkspace class to do what it was > originally designed to do ... provide the list of launched apps as > supplied by the workspace manager. That would be a small modification > to NSWorkspace and to GWorkspace. However, we would want some fallback > option for if/when GWorkspace is not running. Perhaps a minimal > workspace manager daemon, or perhaps NSWorkspace could write to a small > database (eg a plist file in a temporary directory) to maintain the > state information. The latter has the advantages of not requiring an > additional daemon to run (I have no problem with daemons, but I know > many people have objections to them) and is persistent if the workspace > manager is restarted (we need that). The former has the advantages > that it would provide a testbed and reference implementation for > workspace managers. I suppose we could do both. I could very well be missing something obvious but I seems to me that gdnc would be a good candidate to provide this service. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 23 Jan 2006, at 16:38, Fred Kiefer wrote: Roman Belenov wrote: 1) How to get a list of all running GNUstep applications ? launchedApplications seems to return only the list of apps launched from the current one. For now I just use a list of message ports obtained by examining corresponding subdirectory and treat everythying as a proxy for application. We really should get [NSWorkspace launchedApplications] working. Some years ago I suggested a solution for this involving some extensisons to gdomap. Now with gdomap being used less often we will need a more general way to implement it. Perhaps there is the possibility to extend NSPortnameServer (or rather its subclasses) to return a list of all known ports. The NSWorkspace method would then only need to filter out the no longer working ports and restict the returned list to the ones representing applications. Richard, do you like that concept and would you be willing to implement the base part of it? More or less it would be an official implementation of what Roman is doing anyway. I think the concept is fundamentally broken ... since the list of ports is not the list of applications, so you would need to filter them in some way (which probably means an intrusive probe of some sort applied to all the ports which are not application ports), and while any programs using ports should not care about being sent unexpected messages, they are entitled to be annoyed by it. The issue needs fixing at the gui library level, listing launched applications is not an issue for the base library and is not related to ports except in a very incidental manner. We could finish getting the NSWorkspace class to do what it was originally designed to do ... provide the list of launched apps as supplied by the workspace manager. That would be a small modification to NSWorkspace and to GWorkspace. However, we would want some fallback option for if/when GWorkspace is not running. Perhaps a minimal workspace manager daemon, or perhaps NSWorkspace could write to a small database (eg a plist file in a temporary directory) to maintain the state information. The latter has the advantages of not requiring an additional daemon to run (I have no problem with daemons, but I know many people have objections to them) and is persistent if the workspace manager is restarted (we need that). The former has the advantages that it would provide a testbed and reference implementation for workspace managers. I suppose we could do both. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
Roman Belenov wrote: > > 1) How to get a list of all running GNUstep applications ? > launchedApplications seems to return only the list of apps launched from the > current one. For now I just use a list of message ports obtained by examining > corresponding subdirectory and treat everythying as a proxy for application. > We really should get [NSWorkspace launchedApplications] working. Some years ago I suggested a solution for this involving some extensisons to gdomap. Now with gdomap being used less often we will need a more general way to implement it. Perhaps there is the possibility to extend NSPortnameServer (or rather its subclasses) to return a list of all known ports. The NSWorkspace method would then only need to filter out the no longer working ports and restict the returned list to the ones representing applications. Richard, do you like that concept and would you be willing to implement the base part of it? More or less it would be an official implementation of what Roman is doing anyway. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 1/23/06, Roman Belenov <[EMAIL PROTECTED]> wrote: > I hacked a bit trying to implement logoff with graceful application > termination on GNUstep and got some questions: [...] The way I see it would be sending a NSWorkspaceWillPowerOffNotification when "Logout" (or similar) is clicked to the Workspace / Desktop / Window Manager. The Manager would then use -launchedApplications to send each application a terminate message. Problem is that there currently is no 'real' GNUstep-based XY Manager that implements the above. This could be "fixed" if (for example) GWorkspace could also act as a window manager, to replace the 'need' of Window Maker. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
On 23 Jan 2006, at 08:50, Roman Belenov wrote: I hacked a bit trying to implement logoff with graceful application termination on GNUstep and got some questions: 1) How to get a list of all running GNUstep applications ? launchedApplications seems to return only the list of apps launched from the current one. For now I just use a list of message ports obtained by examining corresponding subdirectory and treat everythying as a proxy for application. Well, the way workspace operations generally *should* work as I understand it, is that they should contact the workspace manager application and ask it to do the job for them. There is partial support for this in the NSWorkspace class, but it has never been completed. Basically, the idea is that the local NSWorkspace instance should first try to ask the workspace manager application to do jobs, and if no application is found, it should do the best it can. In the case of launched tasks, this means that every application keeps track of any tasks it sees being launched, but since there is no workspace application launching all tasks, there is no central repository of all the information. So, what you should ideally be doing is fixing that ... Problem is that it was never completed because to make it useful there needs to be a workspace manager application and when I wrote it no such application existed. Then later Enrico wrote GWorkspace without much attention to integration with the NSWorkspace class, and we never got together to make it all work. 2) What is the correct way to check the result of sending terminate to application (from another one) ? Experiments show that if application actually terminates, I get an exception caused by connection timeout. Yes .. you expect the connection to go away when the app terminates. I don't think there is any realistic way you can be absolutely sure an app has completely gone away (though you could try registering a port using the name of the task ... if it works then the app has gone ... if it fails either the app is still running or another app with the same name has started). It's probably best to just assume that loss of the connection to the app means that it has died. Of course, in the case of the workspace manager application (which should generally have launched the app and be responsible for shutting it down too), you have an NSTask object corresponding to the launched application, so you can check the NSTask instance to see if the application is still running after it has been told to terminate. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Graceful termination again
I hacked a bit trying to implement logoff with graceful application termination on GNUstep and got some questions: 1) How to get a list of all running GNUstep applications ? launchedApplications seems to return only the list of apps launched from the current one. For now I just use a list of message ports obtained by examining corresponding subdirectory and treat everythying as a proxy for application. 2) What is the correct way to check the result of sending terminate to application (from another one) ? Experiments show that if application actually terminates, I get an exception caused by connection timeout. So, currently I have a StepTalk script that works on my system (basically, it iterates through message ports, sends terminate to everyone, treats return without exception as a request to cancel session termination). I can post it here, if anyone is interested, though integrating this functionality (after correcting the workarounds) to Login.app seems to be the right way (it can provide a service to make logoff/poweroff/etc. accesible from application menu). PS Also, it would be nice to get the return value of the top-level StepTalk function from stexec (makes sence if it is boolean or integer), that would make its usage from shell scripts easier. -- With regards, Roman. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
