Bug 91934 - weird behaviour on /quit
Summary: weird behaviour on /quit
Status: RESOLVED FIXED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-23 04:06 UTC by jonas boesch
Modified: 2008-05-13 20:04 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jonas boesch 2004-10-23 04:06:39 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

when i type /quit in konversation, all tabs are closed and i only see an empty window with only the bottom statusbar, but it doesn't shut down the application. 

the empty window looks weird ( buggy ), and i think typing /quit pretty much shows that the user wants to close the application and not just the currently active tabs ....
Comment 1 jonas boesch 2004-10-23 04:11:22 UTC
here to screenshots to illustate the problem: 

before /quit: 

http://lagerhalle.l3m.org/konversation_bug-001.png

after /quit:

http://lagerhalle.l3m.org/konversation_bug-002.png
Comment 2 Ismail Donmez 2004-10-23 12:05:18 UTC
Hmm maybe we can quit if there is no server tabs left. Needs discussion.
Comment 3 John Tapsell 2004-11-25 08:38:39 UTC
We could bring up the server list window.  Would this satisfy everyone?
Comment 4 jonas boesch 2004-11-25 22:48:26 UTC
On Thursday 25 November 2004 08:38, John Tapsell wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=91934
>
>
>
>
> ------- Additional Comments From johnflux hotmail com  2004-11-25 08:38
> ------- We could bring up the server list window.  Would this satisfy
> everyone?

Hmm, maybe a config-toggle if /quit should really quit the program or show the 
serverlist? 
Being used to BitchX, i think there should at least be a possibility to /quit 
the program from the lineinput......

Comment 5 Ismail Donmez 2004-11-26 08:30:37 UTC
Yes This would be good. An option to choose if /quit quits the program
if there is one server open or opening config dialog.


On 25 Nov 2004 21:48:37 -0000, jonas boesch <kde@l3m.org> wrote:
> Hmm, maybe a config-toggle if /quit should really quit the program or show the
> serverlist?
> Being used to BitchX, i think there should at least be a possibility to /quit
> the program from the lineinput......
> 


Comment 6 Torrie Fischer 2005-11-21 03:43:34 UTC
How about a /disconnect command to quit from one server, and /quit to disconnect from all servers and close the program?
Comment 7 argonel 2006-01-11 07:03:46 UTC
We have control-q for closing all the windows and quitting the client, why would it need to be duplicated in a command?
Comment 8 Torrie Fischer 2006-03-10 00:37:30 UTC
Because this is a usability issue, not a developer-not-wanting-to-add-another-command issue. Most people are used to /quit completely quitting the client, and /disconnect disconnecting from the current server.
Comment 9 illogic-al 2006-03-11 18:36:53 UTC
How is this a usability issue? How does it really effect the efficiency with which someone uses the program. It doesn't, it's just a different way to do things from other clients which doesn't automatically mean "usability problem".
NOw I'm not saying /quit shouldn't quit, just pointing out that this is not some usability problem, just a different way of using things which you don't like :-) 
Comment 10 Eike Hein 2006-03-11 18:56:56 UTC
You got something wrong there :-). Usability doesn't equal "efficiency". 

At a basic level, something is usable when it behaves like the user expects it to. I have no hard data (and that would be needed to make it a valid usability claim), of course, but I speculate that quitting on /quit would conform to many a user's expectations. 

And that's how this matter relates to usability.
Comment 11 illogic-al 2006-03-11 21:32:23 UTC
> Usability doesn't equal "efficiency". 
Well we disagree on this point then. 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.

> but I speculate that quitting on /quit would conform to many a user's expectations. 
I agree, and not just because I'm one of those users :-) 
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. Is the main function of konversation to quit IRC? How is this feature impeding users from communicating on IRC? 

Anyway this probably isn't this best forum to discuss this, that's why  we have irc. 
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. Personally I used to want the feature being asked for, and agree that /quit would be expected to quit the server and the program. After using it I have definitely found it eaiser and _useful_ to actually have the program open, but serverless. And in any case, ctrl+q is way easier than /quit to type. 
Comment 12 Eike Hein 2006-03-11 21:54:58 UTC
> 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.
Comment 13 argonel 2006-03-14 22:14:40 UTC
The only way I can see that a user gets the expectation that /quit
should close the application is exposure to other IRC clients which
may well be doing things incorrectly. Should we copy a poor
implementation?

So perhaps we're talking about the origin of the expectation. While
making /quit entirely exit the application would fulfill the
expectations of some, for others it would be a complete and annoying
surprise. If we could accurately gauge the users initial expectation
and turn this into a satisfying set of defaults, making this
configurable might be useful. But we don't gather any such
information, so the only expectation we should be setting for the user
is that the client follows the protocol.

In fact, it could be that closing anything other than the socket on
the basis of /quit is wrong. For instance, check out xchat. /quit
merely closes the connection - /close is what disposes of tabs or
quits the application.

QUIT, an IRC protocol command, quits the *connection*, not the
application. Reflect on the fact that the QUIT command takes an
argument which is the text to send for the channel visible IRC quit
message. How does one prevent the sending of the default quit message?
Very simple: use the IRC protocol. "/quit :"

We have in other situations of a similar nature decided to remain true
to the IRC protocol, instead of having Konversation isolate the user
from the vagaries of how IRC actually works. By changing what /quit
does, we present an unpredictable subset of commands that don't work
like their IRC counterparts. Where does the someone get the
expectation for this?

An option for those that want the client to quit is for us to create a
command-option of some sort, which you could then alias for /quit. As
yet we have no standard for command options, one would have to be
developed.

(if this message shows up again without this line, then i apologize in advance. somehow the message was sent but didn't arrive until after my patience had run out :)
Comment 14 Eike Hein 2006-03-14 22:18:20 UTC
That QUIT is defined not only by the KDE platform but also and especially by the IRC protocol is certainly a good argument and food for thought. 
Comment 15 Eike Hein 2008-05-01 12:46:33 UTC
In SVN (and the upcoming 1.1), the '/quit' command closely reflects what happens on an IRC protocol level: A QUIT command is sent to the server, which in response will cut the connection. That leaves a disconnected server status tab - and, with our recent decision to keep channel tabs open on disconnects and improvements to the rejoin-on-reconnect code paths, all the other tabs, too. Thus, '/quit' is currently essentially identical to '/disconnect'. 

So, the behavior has changed, but the question still stands. Leave it as it is now, or close the tabs, or quit the app.
Comment 16 argonel 2008-05-13 20:04:17 UTC
SVN commit 807364 by argonel:

Add a /close command to allow chats, queries, dccchats and servers to be closed from the input box.
BUG:91934


 M  +9 -11     channel.cpp  
 M  +1 -1      channel.h  
 M  +2 -2      chatwindow.cpp  
 M  +1 -1      chatwindow.h  
 M  +11 -3     dccchat.cpp  
 M  +1 -1      dccchat.h  
 M  +17 -0     outputfilter.cpp  
 M  +1 -0      outputfilter.h  
 M  +7 -10     query.cpp  
 M  +1 -1      query.h  
 M  +9 -0      queuetuner.cpp  
 M  +2 -1      queuetuner.h  
 M  +7 -0      server.cpp  
 M  +3 -1      server.h  
 M  +8 -3      statuspanel.cpp  
 M  +2 -1      statuspanel.h  
 M  +8 -8      viewcontainer.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=807364