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 ....
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
Hmm maybe we can quit if there is no server tabs left. Needs discussion.
We could bring up the server list window. Would this satisfy everyone?
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......
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...... >
How about a /disconnect command to quit from one server, and /quit to disconnect from all servers and close the program?
We have control-q for closing all the windows and quitting the client, why would it need to be duplicated in a command?
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.
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 :-)
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.
> 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.
> 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.
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 :)
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.
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.
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