Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on the Quit command

>I'm afraid "safely" is a relative term, and depends entirely on how well
>the app in question is written.

Agreed. In a perfect world, all applications would be perfectly behaved.
Given that it isn't, I wouldn't want to make it easier to make a
badly-behaved app to behave badly.

>Given that Force-Quit is available, I think the least Apple should do is
>remove the cmd-Q from the Application menu's Quit command. That alone
>would solve the problem of accidental cmd-Q "summary exit", yet still leave
>desperate users an out (with Force-Quit) for Truly Ill-behaved Programs.
>Well-behaved programs, of course, have their own Quit/Exit menu-item.

I would agree with this, but I'm guessing that Apple would be unyielding
about it because of the inconsistency and the fact that Force Quit it
still seen as the province of "stuck" programs, not simply programs that
don't have a Quit.

As noted by someone else, Force Quit doesn't currently register running
Java apps that are running unless they have a Mac OS X native wrapper (I
think...I'm not absolutely sure), so that would have to be fixed. It
would also be ok with me too if Force Quit were "smart" and did a
System.exit() the way the current Quit command does when running a Java
app...I would say there's some precedent for this (special-case Force
Quit behvaiors), because it will allow you to Force Quit a Classic app
without killing Classic entirely (sometimes).

Most of my comments were written under the assumption that having Quit in
the Application menu is something Apple would be unwilling to compromise
on, as indicated by the (new) inability to remove it. I am with you in
that think that not having it there at all would be the best option. In
my view the second best option would be to remove the keyboard shortcut
and relabel it "Force Quit." Most people know that a Force Quit isn't
something to be casually done, and it would distinguish it from any other
Quit the application might have, and yet provide an obvious way out if
there is no other.

>Yes, it would still be confusing to see a Quit item under the Application
>menu as well as under the File menu, but I'm afraid there aren't a lot of
>other options. The standard tacit assumption is that Quit/Exit is under
>the File menu, just as The Macintosh revealed to us in its First Coming,
>and as all humanity has come to believe since.

>Looking for "Quit" in an app's File menu is hugely error-prone. Even in US
>English, the menu-item name might be "Exit" instead of "Quit", and it will
>certainly be something else in every other human language.

Good point, I was being English-centric when I thought of it...though I
did suggest looking for "Quit" OR "Exit". Would it not be possible to use
the various Mac OS X localization packages available to figure out what
it might say in other languages? Of course, this would begin to get a
fair bit unwieldy very quickly so I think your point is made. The idea
still appeals to me as a neat hack, though...just hook into where the
program obviously exits, and if it can't find anything, then it doesn't
do anything different than it does already.

I don't see having a Quit command in both the File and application menus
as being a major issue though -- I just think that if there is going to
be both, then they should do the same thing -- having them do DIFFERENT
things (which could well be transparent to the user) strikes me as very
bad user experience.

Apple, incidentally, advises (in TN 2042) putting Quit in the File menu
platform-conditionally...but again, that doesn't do us much good if we're
running software from a non-Mac source.

>A com.apple.mrj.apple.menu.quit property doesn't solve anything, unless
>it's to ENABLE the menu-item in the Application menu. If it disabled the
>menu-item, then you're going against your earlier principle of being able
>to run any Java program, regardless of whether the author even knows what a
>Mac is.

Again, it was suggested working from the assumption that Apple would
always want to have the Quit available for applications which there was
no way out of. But it's true that it wouldn't accomplish much. I don't
follow you though about it would impact it would have one way or the
other on being able to run a Java program or whatever source.

>Incidentally, Unix has a slightly similar problem in that signals can
>summarily force a program to exit (Windows has some similar signals, too).
>Sometimes this is desirable, but other times it's really bad. Worse, the
>standard behavior is to emit a thread-dump for some signals, which is
>certainly not the intent of some of the signals (e.g. SIGHUP). Catching
>and handling signals under Unix is covered by my open source Easy Posix
>Toolkit:
> <http://www.amug.org/~glguerin/sw/#easyposix>
>
>I think it's a decent design and set of abstractions, however, I only
>provide a Mac OS X implementation.

That's pretty cool...I'm going to check it out.


Ivan.
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.