[Konversation-devel] [Bug 91934] weird behaviour on /quit

[Eike Hein]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=91934         




------- Additional Comments From sho eikehein com  2006-03-11 21:54 -------
> Changes which are supposedly to improve usability which do not yield a more productive, efficient use of an interface are pointless and really aren't. 

I was really channeling Joel Spolsky there for a moment: http://www.joelonsoftware.com/design/1stDraft/03.html

It's worth a read.


> However arguing for this bug on the grounds of usability, in my non-professional opinion, is just a stab at making it seem more important than it really is by tacking the word usability onto it.

I think you're perhaps negatively overreacting to the recent rise in the importance of usability factors within KDE/FOSS. When I say this matter is related to usability, I mean that quite innocently and not with the agenda to employ the trendy term of the day for my cause (which isn't really my cause to begin with, I was just uttering my opinion).


> I find it funny that no one has voted for this bug though, the impression i get is that most users really don't care.

Well, keep in mind the size of the audience and the percentage of which are regularly reading the bugtracker. You'll be hard-pressed to find the necessary momentum for many votes no matter the issue.

--- snip ---

Anyway, let's sum things up. We've got a /quit command and are faced with the decision how it should behave. There are a number of options on the table:

1. Close the server connection of the current context. Dispose of all related tabs. If it's the only remaining connection, leave a blank canvas and do nothing.

This is a safe option and one I'm reasonably happy with. We could try to extend this scheme by popping up the Server List dialog at this point or asking the user whether to quit. I'm not a big friend of dialogs appearing without a very specific request, however.


2. Close the server connection of the current context. Dispose of all related tabs. If it's the only remaining connection, quit the application. Integrate with the 'Warning Dialogs' mechanic.

Don't like this one. Closing all open connections and starting from scratch is a legitimate usage scenario. Thus if '/quit' works per-connection, it doesn't make sense to invoke the Quit verb on the last remaining one.


3. No matter how many connections are active, quit the application. Integrate with the 'Warning Dialogs' mechanic.

Seems best to me. Conforms with many other IRC clients, and makes keeps the meaning of the 'Quit' verb consistent with the menus and shortcuts: It's about quitting the app, lad. Due to how 'Quit' is used elsewhere in KDE apps and the behaviour of other IRC clients, I think there's a serious argument here that this is what users are likely to expect from '/quit'. That would make it desirable for usability reasons unless the alternatives would be significantly better, which I don't think they are. The per-connection abort can be handled by '/disconnect' quite nicely.