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: Repository change to SVN, Jan 28th
Am 22.01.2006 um 19:04 schrieb David Ayers: - what goes into tag? When? You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. Is there actually reason for tagging? As tags and branches are technically the same, shouldn't copies made according to a release go into branches/ directly? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/back ChangeLog Headers/cairo/Cairo...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer <[EMAIL PROTECTED]> 06/01/23 20:51:40 Modified files: core/back : ChangeLog core/back/Headers/cairo: CairoFaceInfo.h core/back/Source/cairo: CairoFaceInfo.m CairoFontEnumerator.m CairoFontInfo.m Log message: Made the cairo backend compile with the current cairo CVS version. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.407&tr2=1.408&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoFaceInfo.h.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFaceInfo.m.diff?tr1=1.5&tr2=1.6&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFontEnumerator.m.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFontInfo.m.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
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: Repository change to SVN, Jan 28th
David Ayers wrote: Sheldon Gill schrieb: David Ayers wrote: You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. It's not like gnustep is seeing the kind of development activity like, say, GCC. But maybe you have something specific in mind? Main releases are obvious. I'm wondering about branch snapshots. Not sure why you'd want a snapshot of a branch unless your releasing from branch (as in dedicated release branches with bugfix releases à la GCC). I was thinking of two things here: One is branch releases where a branch is somewhat experimental. This would help with testing and review. The other is bugfix releases, ala GCC. - Are we going to import more vendor trees? (like ffcall, portaudio etc) I think we should keep anything not FSF assigned in a separate repository so we have clear boundaries from where we can blindly copy-and-paste code. Other than that I think there should be a dedicated maintainer(s) for any external vendor tree who will keep them up to date. I'm not sure we need a separate repository. Wouldn't a vendor directory tree would make the boundary equally clear? Other than that, I'm in agreement with this. IMO the copyright assignment boundary should be pretty clear especially if we have all projects at top level as was originally proposed, IIRC. I'm still in favor of a separate repository, but that's just my opinion. Same or separate, as long as the boundary and use is clear. I wasn't thinking of having vendor items mixed in at the top level with the rest of GNUstep items. Rather a separate directory, so it's apparent they are in the Vendor tree. (Or whatever we choose to call it) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/usr-apps/SystemPreferences/Modules/Volu...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Enrico Sersale <[EMAIL PROTECTED]> 06/01/23 11:36:32 Modified files: usr-apps/SystemPreferences/Modules/Volumes: Volumes.m Log message: CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/SystemPreferences/Modules/Volumes/Volumes.m.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
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
[Gnustep-cvs] gnustep/usr-apps/SystemPreferences/Modules File...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Enrico Sersale <[EMAIL PROTECTED]> 06/01/23 13:23:22 Modified files: usr-apps/SystemPreferences/Modules/FileSystem: FileSystem.m usr-apps/SystemPreferences/Modules/ModifierKeys: ModifierKeys.m usr-apps/SystemPreferences/Modules/TimeZone: TimeZone.m usr-apps/SystemPreferences/Modules/Volumes: Volumes.m Log message: CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/SystemPreferences/Modules/FileSystem/FileSystem.m.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/SystemPreferences/Modules/ModifierKeys/ModifierKeys.m.diff?tr1=1.2&tr2=1.3&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/SystemPreferences/Modules/TimeZone/TimeZone.m.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/SystemPreferences/Modules/Volumes/Volumes.m.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
[Gnustep-cvs] gnustep/usr-apps/gworkspace FSNode/FSNodeRep.m ...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Enrico Sersale <[EMAIL PROTECTED]> 06/01/23 15:24:02 Modified files: usr-apps/gworkspace/FSNode: FSNodeRep.m usr-apps/gworkspace/GWorkspace: GNUmakefile.in GWorkspace.h GWorkspace.m usr-apps/gworkspace/GWorkspace/Desktop: GWDesktopManager.h GWDesktopManager.m GWDesktopView.m usr-apps/gworkspace/GWorkspace/Preferences: PrefController.m Removed files: usr-apps/gworkspace/GWorkspace/Preferences: VolumesPref.h VolumesPref.m usr-apps/gworkspace/GWorkspace/Resources/English.lproj/VolumesPref.gorm: data.classes data.info objects.gorm Log message: CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/FSNode/FSNodeRep.m.diff?tr1=1.40&tr2=1.41&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/GNUmakefile.in.diff?tr1=1.39&tr2=1.40&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/GWorkspace.h.diff?tr1=1.59&tr2=1.60&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/GWorkspace.m.diff?tr1=1.112&tr2=1.113&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/Desktop/GWDesktopManager.h.diff?tr1=1.11&tr2=1.12&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/Desktop/GWDesktopManager.m.diff?tr1=1.17&tr2=1.18&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/Desktop/GWDesktopView.m.diff?tr1=1.14&tr2=1.15&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/Preferences/PrefController.m.diff?tr1=1.11&tr2=1.12&r1=text&r2=text
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Mon Jan 23 06:34:13 EST 2006 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf3.0 Mon Jan 23 03:58:31 CET 2006 Success Compile powerpc-apple-darwin7.9.0 Mon Jan 23 03:24:38 MST 2006 Success Compile sparc-sun-solaris2.7 Mon Jan 23 02:08:49 EST 2006
Re: Repository change to SVN, Jan 28th
Sheldon Gill schrieb: > David Ayers wrote: > >> You mean other than releases? Well since we have defined repository >> states through revision numbers, I can't think of any necessity for more >> tags. It's not like gnustep is seeing the kind of development activity >> like, say, GCC. But maybe you have something specific in mind? > > > Main releases are obvious. I'm wondering about branch snapshots. Not sure why you'd want a snapshot of a branch unless your releasing from branch (as in dedicated release branches with bugfix releases à la GCC). >>> - Are we going to import more vendor trees? (like ffcall, portaudio >>> etc) >> >> >> I think we should keep anything not FSF assigned in a separate >> repository so we have clear boundaries from where we can blindly >> copy-and-paste code. Other than that I think there should be a >> dedicated maintainer(s) for any external vendor tree who will keep them >> up to date. > > > I'm not sure we need a separate repository. Wouldn't a vendor directory > tree would make the boundary equally clear? > Other than that, I'm in agreement with this. > IMO the copyright assignment boundary should be pretty clear especially if we have all projects at top level as was originally proposed, IIRC. I'm still in favor of a separate repository, but that's just my opinion. Cheers, David ___ 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
Re: Problems with automatic start of gdnc, gpbs, and gdomap on Linux...
Gregory John Casamento <[EMAIL PROTECTED]> writes: > The subject basically says it. When I log in, it's reporting that it had > trouble starting gdnc. Is anyone else having this problem? I had such problems, but they disappeared with latest (1.11.2) release of base, probably the following entry in Changelog is relevant: 2005-11-20 Richard Frith-Macdonald <[EMAIL PROTECTED]> * Source/NSDistributedNotificationCenter.m: Rewrite code for connecting to and starting up daemon to handle the process more quickly and smoothly. Only complain if we can't to connect to it even after launching it and retrying the connection for five seconds. -- With regards, Roman. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
