1) Responsive UI, or "If the user says Close, we Close, no ifs ands or buts.":
Then go tell Microsoft Word they aren't supposed to give users a last chance to save documents. Or go tell themselves they can't ask for confirmation to exit when there's connections open.
...
But there are *plenty* of examples of windows programs (and GUI apps in general) that do not just go *zap* when you hit the X. If X was supposed to mean DIEDIEDIE windows wouldn't even give an option to cancel the event, now would it?
This logic is so flawed it amazes me it came from a developer (even an unrealircd one)... When Word gives you a chance to save your documents or mirc asks confirmation to exit, the GUI is being completely responsive. The window doesn't close but another event happens
immediately instead: a warning box pops up, informing the user what's going on and asking for further action. This is very different from delaying an action, giving no indication to the user that mirc is waiting for something before it closes the window. To make the distinction even clearer, consider the aforementioned example of mirc asking for confirmation to exit. If the user clicks OK on the confirm dialog box, mirc exits immediately (or almost immediately), ie it doesn't wait for the server to tell it "ok, I acknowledged your quit" before it closes its window. See the difference? Confirmation dialogs have nothing to do with UI responsiveness.
However the above was just to illustrate why confirmation dialogs are a terrible analogy. The actual (and rather perplexing to me) issue is that some people seem to actually prefer experiencing obscure delays in window closing that may last quite a while, depending on network conditions etc. And for what purpose? Does the idea that a channel window might be closed a little while before the client receives the PART reply shock them that much?
