Bug 136743 - Turn parameter-less /away into a toggle as a compromise between modern and legacy behavior
Summary: Turn parameter-less /away into a toggle as a compromise between modern and le...
Status: RESOLVED FIXED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
: 139938 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-11-02 22:54 UTC by Marcus Wolschon
Modified: 2007-01-12 14:23 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 Marcus Wolschon 2006-11-02 22:54:03 UTC
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.
Comment 1 Eike Hein 2006-11-02 23:04:08 UTC
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. 
Comment 2 Stephanie Daugherty 2006-11-03 00:35:45 UTC
I don't consider notstandard behavior acceptable either. Please reconsider.
Comment 3 Eike Hein 2006-11-03 00:51:52 UTC
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.
Comment 4 Stephanie Daugherty 2006-11-03 00:59:56 UTC
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.

Comment 5 Eike Hein 2006-11-03 01:46:13 UTC
> 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.)
Comment 6 illogic-al 2006-11-04 01:47:45 UTC
I'm w/ Steph and original reporter on this one. And the compromise suggested by eike is a good one.
Comment 7 Eike Hein 2006-11-04 02:01:41 UTC
Reopening to track the implementation of the proposed compromise.
Comment 8 Peter Simonsson 2006-11-04 23:24:17 UTC
Ok compromise is implemented in svn trunk, rev 601986
Comment 9 Eike Hein 2007-01-12 03:17:45 UTC
*** Bug 139938 has been marked as a duplicate of this bug. ***
Comment 10 Eike Hein 2007-01-12 14:23:59 UTC
*** Bug 139938 has been marked as a duplicate of this bug. ***