When sending a quit message to Colloquy, the warning requester shouldn't appear

[Allan Odgaard]

A few upgrades ago, Colloquy got a confirmation requester when quitting it.

Though there are a few ways to quit Colloquy w/o having the actual application active, like sending an apple script message, using the dock menu, pressing cmd-q while the app switcher (cmd-tab) is up and Colloquy is selected, etc.

IMHO Colloquy should not show the confirmation requester for any of these scenarios, and I'd much appreciate if (preferably) the behavior was changed, or (if you disagree) a (hidden?) preference was added to allow me to quit the application w/o having to activate it first (i.e. using one of the methods mentioned above).

[Allan Odgaard]

This is also killing automatic shutdown

[petermcm]

I'd personally like to have this as a preferences option: "Prompt on quit if connected" (See also #498).

The prompt itself could have a "This option can be changed in prefs" note, or a "Don't ask again" thing.

[petermcm]

...or even better, a list of checkbox options in preferences where you can specify:

Prompt on quit if:

• There are active file transfers
• Connected to a server
• Connected to a channel
• There are unread messages
  • ...In which I was mentioned

[xApple]

I agree, this quit dialog is really bothersome. Use a preference checkbox combined with a "Don't ask again" checkbox. Your application wonderfully follows the Apple HIG on almost every point except here.

[srbennetandjmink]

Includes the diff and copies of the appropriate .nib files

[srbennetandjmink]

The patch uploaded currently makes quit promting a preference which can be disabled. It does not, however, have a check-box on the quit prompt and can only be modified through the preference menu.

[srbennetandjmink]

Includes quit preference and the option to change your preference from the quit dialog

[prophile]

Hidden preference patch

[prophile]

Added a tiny patch to hide the quit prompt.

You have no excuse not to roll this in!

[siege]

Timothy, is there any feedback you would mind giving on this defect and the submitted patches?

[Rinoa]

Valid as of latest build.

[Billy]

The quit message is literally the most annoying thing about an otherwise great program. I would love to use Colloquy, but that quit message is a dealbreaker — I use XChat Aqua instead because it doesn't have a quit message.

Quitting is not an action that will produce irrevocable changes — you can always just start the program again. If you don't want to lose the transcript of the current session, you should turn on logging. At the very least the quit message should be removed entirely. Better would be to have it off by default and a preference to turn it on if desired. Having it on by default with a preference to turn it off is slightly less desirable, but having no preference for it whatsoever is just poor design in my opinion and not in the spirit of the HIG.

I can not once in my entire life remember having accidentally quit a program. And accidentally quitting an IRC client has no consequences whatsoever even if you were to do so. If I wanted to have to confirm every single action I perform, and to have to constantly dismiss inane little popups, I would be using Windows.

[zach]

An open connection is very much a volatile connection. In Colloquy, it is possible to create a new connection without checking the box to save it. It is possible to join rooms without adding them to your autojoin or favorites list. You can have private messages or notices open as well, that may not get logged either. And not everyone wants logging to be enabled, but still wants to be able to scroll back up to earlier in the afternoon on occasion.

I can not once in my entire life remember having accidentally quit a program. And accidentally quitting an IRC client has no consequences whatsoever even if you were to do so.

It is quite easy to hit cmd q instead of cmd w or cmd a. Its a common mistake to happen.
And you may use IRC for general chat, other people can and do use it for work, where quitting at the wrong time would be very bad.

Also, you can already use opt + cmd + q to quit without the confirmation message.

[Billy]

No, no, no, no, no. Just everything you said: no. You are completely wrong. People keep opening tickets asking to have this removed, and you can't see past your own idiosyncratic preference on the matter. You are too close to the forest to see the trees.

In Colloquy, it is possible to create a new connection without checking the box to save it.

Safari does not ask for confirmation before quitting just because I opened a webpage but didn't bookmark it.

If you accidentally quit (which, I will repeat, does not ever happen), it is nothing more than the most minor of inconveniences to just open the program again and just reenter the connection details.

It is possible to join rooms without adding them to your autojoin or favorites list.

Yes, because, presumably, people don't want to join those rooms again the next time. You'll note that when you have multiple tabs open in Safari, an exact analog to being in multiple rooms, the default behavior is to ask you if you're sure you want to quit. But note that there is a preference to turn this off!

You can have private messages or notices open as well, that may not get logged either.

So show the message if you have unread private messages or notices, but not otherwise! Seriously, you're bringing up these edge cases that simply do not justify annoying the hell out of people in the vast majority of realistic use cases.

And not everyone wants logging to be enabled

If you are scared of being such a butterfingers that you accidentally quit the program (which, I will repeat, does not ever happen), but you simply stubbornly don't want to turn logging on, then too bad. Pissing off every single other person who uses the program every time they use it completely outweighs the case of the butterfingers who—for no good reason—doesn't want to turn on logging.

It is quite easy to hit cmd q instead of cmd w or cmd a. Its a common mistake to happen.

No, it's not a common mistake. It's not quite easy to do that. I have never in my entire life done that. Saying it's a common mistake is wishful thinking. How many times have you done it yourself?

I don't disagree that someone could accidentally quit the program. But a tsunami could also hit land and wash your entire office away while you have unsaved connections. Are you going to implement a poller that parses the NOAA Pacific Tsunami Warning Center's RSS feed every minute and pops up a warning to save your unsaved connections before the impending tsunami makes landfall? No, of course not—because that would be ridiculous. It just doesn't happen enough to worry about.

And you may use IRC for general chat, other people can and do use it for work, where quitting at the wrong time would be very bad.

I do indeed use it for work—and that's exactly why this message annoys the hell out of me! Again, turn logging on if you are one of the handful of people discussing something so critical on IRC that quitting the program accidentally would cause catastrophic loss to your business. I may be mistaken here, but as far as I know the US missile defense system isn't controlled through IRC, and the missiles don't launch when a client accidentally disconnects.

Also, you can already use opt + cmd + q to quit without the confirmation message.

No, that's not good enough. You don't have to go out of your way to hit that key combination in any other software, so that's a bad solution. No one's going to remember to use that. When you want to quit, you hit Cmd-Q, and the program disappears. Blocking that behavior with a modal dialog completely breaks that expectation.

I think it's clear that you're thinking of a very specific use case where someone starts Colloquy, opens up twelve new connections without saving them, and then joins a dozen rooms on each connection without setting them to auto-join. But nobody would do that and expect the program to somehow step in and prevent them from accidentally quitting. Anybody who has such an intricate setup would save the connections and set everything to auto-join so that it's recreated the next time they start the program.

Again, since this is obviously undesired behavior for a lot of people, I simply don't see why you don't add a preference for it, especially when people went out of their way to provide patches. You have so many other preferences already in there that make less sense than this one. Just because you think the quit warning is a good idea in theory doesn't make it a good idea in practice.

I'm aware that I'm being antagonistic, but the fact that you are simply discounting the criticisms people have of this default behavior as unjustified—and furthermore refusing to apply a patch people have gone out of their way to prepare that would make everyone happy—makes me almost as angry as the presence of the message itself.

[lighteater]

I strongly agree with Billy. This is a really annoying feature and the reasoning for keeping it is outrageously silly.

For people who can type properly and don't tend to 'acidently' quit their applications a suitable preference should be added to turn this off.

I mean really, what kind of a person can't understand a different view and refuse to implement a sensible feature that would take roughly 20 minutes of his time?

[timothy]

This was added for a reason — it was asked for by more people than have asked to see it removed.

Sure we will add a setting, and it will be on by default.

This is easier to do in Leopard anyway, with NSAlert API.

/* -setShowsSuppressionButton: indicates whether or not the alert should contain a suppression checkbox. The default is NO. This checkbox is typically used to give the user an option to not show this alert again. If shown, the suppression button will have a default localized title similar to @"Do not show this message again". You can customize this title using [[alert suppressionButton] setTitle:]. When the alert is dismissed, you can get the state of the suppression button, using [[alert suppressionButton] state] and store the result in user defaults, for example. This setting can then be checked before showing the alert again. By default, the suppression button is positioned below the informative text, and above the accessory view (if any) and the alert buttons, and left-aligned with the informative text. However do not count on the placement of this button, since it might be moved if the alert panel user interface is changed in the future. If you need a checkbox for purposes other than suppression text, it is recommended you create your own using an accessory view.
*/
- (void)setShowsSuppressionButton:(BOOL)flag;
- (BOOL)showsSuppressionButton;

Someone who cares to see this should attach a patch. I will land it.

[xurizaemon]

As stated above - this defect causes Colloquy to block system shutdown. I would be really happy for this to be optional (and believe that it should also not be the default behaviour, but that's another issue and can be argued another time).

I see that the reasoning above is "more people want Colloquy to prompt on quit than don't", so I'm adding my voice to the number of people who appear to think otherwise. As the bug was marked for fixing in 2.1, and Timothy has agreed to land a submitted patch, and Zach has not explained his reasons for closing this issue, I'm re-opening it.

There was a patch submitted, but that was some time ago.

Are there really intractable philosophical objections in the dev team to making this non-standard behaviour optional?

This issue is old enough to start school. Please, kill it before it hits voting age.