Version: 1.0.1 (using KDE 3.5.5, Debian Package 4:3.5.5a-1 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.16.19 In konversation 1.x "/away" (without arguments) does not unset the away-status set via "/away <message>" as it was before and should be. "/unaway" still works.
This is an intentional change, as noted in the changelog: "If given no parameter, the "/away" command will now set the away state with the default away message. The "/back" and "/unaway" commands can be used to unset the away state." The rationale is that it was reported to us that unsetting the away state with /away is unintuitive (and should rather set the away state with a default away message), and we happen to agree. Many other IRC clients abstract the protocol in the same fashion.
I don't consider notstandard behavior acceptable either. Please reconsider.
Again, Konversation is not the only IRC client that abstracts the IRC protocol in this fashion. Nor does the IRC protocol dictate what user interface a client should present, which includes the behavior of commands. If you're looking to input RAW IRC protocol, I suggest using a telnet client. One compromise I could imagine, however, is implementing /away as a toggle, i.e. a parameter-less /away while being away would unset the away state, while a parameter-less /away while not being away would set it with a default message. While I personally enjoy that a parameter-less away at any time allows me to replace a specific away message with the default one, I can see that as striking a reasonable balance between the expectations of those using legacy IRC clients and the more intuitive behavior we aim at.
I still think that parameter-less /away should always set the client back, but I'd consider treating it as a toggle much more reasonable as a compromise. IMHO, whereever possible, commands that correspond one-to-one to protocol commands should work as closely to how they work in the protocol as practical. Dumbing down the interface makes just as much learning curve for those that already have expectations about how IRC clients are supposed to behave. Realistically, a new IRC user is going to point and click anyway.
> IMHO, whereever possible, commands that correspond one-to-one to protocol commands should work as closely to how they work in the protocol as practical. I disagree, because I don't see the protocol as particularly relevant to the interface presented to the user, nor as a guide on how to implement it. And with AWAY specifically, going by the language in RFC 1459, I don't think it was intended to be, either. This is clearly for machines, not humans. Once you've managed to think outside of the restrictions imposed by trying to model the interface after the low-level protocol, it's pretty apparent that unsetting away by issueing /away is rather moronic and unintuitive (not so for machines, but for humans). And that's what I care about. I'm willing to make concessions to old-timers as the compromise suggested above when I'm reasonably convinced that they won't compromise that premise, but not when they do. > Realistically, a new IRC user is going to point and click anyway. New users don't stay new users for very long: They quickly realize that typing commands is faster than clicking, and gradually adopt the usage of text commands. When they do, it's nice that the commands make sense intuitively, and don't require for them to learn about implementation details of the IRC protocol that modern IRC clients mask. (Taking a quick look at X-Chat, it happens to implement the toggle compromise. Konvi and X-Chat combined make up most of the GUI client market share on the Linux/Unix platform, I'd venture to say.)
I'm w/ Steph and original reporter on this one. And the compromise suggested by eike is a good one.
Reopening to track the implementation of the proposed compromise.
Ok compromise is implemented in svn trunk, rev 601986
*** Bug 139938 has been marked as a duplicate of this bug. ***