I’ve already had a user complaint on this. On Windows Alt+F4 seems like a good window close event, while on Mac, Command-Q seems like it’s a direct end-program with no time to cleanup. Does anyone have experience with this?
Thanks!
Cmd-Q cleans up…
On Mac you should be using Apple’s classes to hook into the Command-Q event. Apple supplies stubs so you can compile on any platform, you just check at runtime if you are on a Mac and activate the hooks. Check the java.net tutorial for bringing your apps to the Mac.
??
Isn’t Java supposed to be cross platform :-[
It is.
What has that got to do with platform specific features like Command-Q ?
If you want to support platform specific things, you need to code for them.
It’s not hard.
Ah… don’t know about command-q, thought it was like alt-f4 in windows, a close application call.
Alt-F4 is a Close Window call, isn’t it?
Command-Q is a quit application call on Mac. It does not have anything to do with closing a window in any direct sense.
in windows, window = application 
… so far I didn’t stumbled on application that dosen’t completely close after alt-f4 (if not ignored of course).
Windows has multi-window applications too… For example: explorer.exe can be configured to run all windows froma single process. GIMP for windows uses multiple windows.
By the sound of it, Command+Q is equivalent to clicking “End Task” in task manager?
If that is the case, unless you specifically want to remap or disable the functionality of Command+Q, should the shutdown code not be performed using the platform independant mechanism exposed through shutdown hooks?
e.g.
java.lang.Runtime.getRuntime().addShutdownHook(new Thread(new CustomCleanerupper()));
No, not at all.
End Task in task manager forcibly shuts down the process on Windows. Your application doesn’t get a chance to do anything, as far as I know.
Command-Q is not a “forced quit”, it’s a “quit request” distinct from a “close window” request. Both Windows apps and Mac apps can run without a window open, though it is more common on a Mac, since it has a screen-level menu bar so you can still interact with the application.
Shutdown hooks are good for clean up, but you can’t stop the shutdown. Mac also has “Forced Quit” which you can get to in a couple ways… one is if the main GUI thread is stuck for too long the doc icon for the app will have “Force Quit” instead of “Quit” in the context menu.
When someone hits Command-Q with an unsaved document, you might pop up a dialog asking “Save your work?”, “Don’t Save”, “Cancel” … so you can cancel the shutdown.
On Mac you want to hook into some standard menus in a Mac-friendly way. On Mac all applications have a “Application” menu that has the name of the app and is the first menu on the menu bar, before the typical File menu. The Quit item always goes in that Menu, the Preferences menu item should always go in that menu, the About item always goes in that menu. It isn’t hard to use the Apple-supplied stub classes to compile something on Windows that would use these items on Mac. It is good practice to detect that you are on a Mac and remove “Exit” from your “File” menu and instead hook the same code up to the Application menu’s “Quit” which is the same thing that happens when you press Command-Q. The same thing should happen with your About item, that would typically be in the Help menu on Windows, but should only be in the Application menu on Mac. Java/Swing doesn’t provide any suitable framework for encapsulating these concepts in a cross-platform way… though I think there is a Swing-related JSR for an Application Framework to address this.
‘End Process’ has the behaviour you describe there.
‘End Task’ appears to behaviour in a near identical fashion to Command+Q.
I assume it sends a message with the meaning of “please terminate the application soon”, because if the application is still active in 5 seconds time the OS assumes it has stopped responding and pops up its own dialog querying whether you wish to forceably terminate the application.
I was completely unaware of the Mac’s standardized mechanism for displaying certain menu items; it is interesting that Swing hasn’t yet addressed this limitation.
A great reason to design applications so they are sufficiently intuitive to not require menu bars! =)