954011 - Enhance UI with IRC features

Status: RESOLVED INVALID

(Instantbird Graveyard :: Conversation, enhancement)

Description

[Benedikt Pfeifer]

*** Original post on bio 574 at 2010-11-07 22:40:00 UTC ***

Copied from bug 953944 (bio 507):

> Patrick Cloke (:clokep) 2010-09-15 21:44:08 CEST
>
> I also intend to add some other IRC features to the UI after the backend is
> rewritten.

Now here's the bug for it.

Comment 1

[Benedikt Pfeifer]

*** Original post on bio 574 at 2010-11-07 22:45:48 UTC ***

I wasn't able to pinpoint whether "PASS" requires services or not (I think it is a built-in thing, but suggesting the following anyways) so this suggestion is based on the assumption that it does:

What if we'd streamline the process of recovering a taken nick or a ghost? Right now it requires one or more commands to nickserv to do so.

It could as well be a command on the context menu that automatically send all necessary commands including the authentification information to the service.


Problems: what if there are no services? Could it be that the password ends with someone impersonating a service, that is taking the nick of one and waiting for people to do exactly this mistake (I think using these nicks is not permitted on many servers but who knows..).

Comment 2

[Benedikt Pfeifer]

*** Original post on bio 574 at 2010-11-07 22:47:13 UTC ***

Oh and another objection: is this case common enough to justify a menu item for it?

Comment 3

[Patrick Cloke [:clokep]]

*** Original post on bio 574 at 2010-11-08 03:23:13 UTC ***

(In reply to comment #1)
> I wasn't able to pinpoint whether "PASS" requires services or not (I think it
> is a built-in thing, but suggesting the following anyways) so this suggestion
> is based on the assumption that it does:
PASS (as I just explained on IRC to an empty room) is a build in command that authenticates to a server, not a nickname (as far as I understand it): See http://tools.ietf.org/html/rfc2812#section-3.1.1 for the exact description
 
> What if we'd streamline the process of recovering a taken nick or a ghost?
> Right now it requires one or more commands to nickserv to do so.
A few things I want to do with this concerning bug 953609 (bio 162) (which I should probably write in that bug), but there should probably be a menu to change your nick with a quick "default nick" button.


> It could as well be a command on the context menu that automatically send all
> necessary commands including the authentication information to the service.

> Problems: what if there are no services? Could it be that the password ends
> with someone impersonating a service, that is taking the nick of one and
> waiting for people to do exactly this mistake (I think using these nicks is not
> permitted on many servers but who knows..).
This is really a bug 953609 (bio 162) issue, my plan is to have it very configurable...I'll respond in that bug though.

Comment 4

[Patrick Cloke [:clokep]]

*** Original post on bio 574 at 2010-11-08 03:45:43 UTC ***

Treating this as a general enhance the UI bug I'm gonna depend on 210 (sort nicknames by rank in IRC rooms).

Comment 5

[Patrick Cloke [:clokep]]

*** Original post on bio 574 at 2010-11-09 17:17:17 UTC ***

Another idea that never seems to have been filed is that we should have a context menu for users on IRC that includes commands that can be run (i.e. kick, etc. for ops, but only whois for non-ops, etc.).

Comment 6

[Benedikt Pfeifer]

*** Original post on bio 574 at 2010-11-09 18:08:12 UTC ***

The context menu is filed as bug 953891 (bio 451). Marking it as blocking this one.

Comment 7

[Florian Quèze [:florian]]

*** Original post on bio 574 at 2010-11-10 08:52:35 UTC ***

(In reply to comment #5)
> Another idea that never seems to have been filed is that we should have a
> context menu for users on IRC that includes commands that can be run (i.e.
> kick, etc. for ops, but only whois for non-ops, etc.).

Wouldn't it provide a better user experience to run whois automatically when the nick is hovered in the list of participants, and display the result in a tooltip like we do for the information about contacts in the buddy list?
Is there anything in the IRC RFC that says or suggests whois should be run only when explicitly requested by the user?

Comment 8

[Patrick Cloke [:clokep]]

*** Original post on bio 574 at 2010-11-10 15:34:56 UTC ***

(In reply to comment #7)
> (In reply to comment #5)
> > Another idea that never seems to have been filed is that we should have a
> > context menu for users on IRC that includes commands that can be run (i.e.
> > kick, etc. for ops, but only whois for non-ops, etc.).
> 
> Wouldn't it provide a better user experience to run whois automatically when
> the nick is hovered in the list of participants, and display the result in a
> tooltip like we do for the information about contacts in the buddy list?
> Is there anything in the IRC RFC that says or suggests whois should be run only
> when explicitly requested by the user?
It would be, I guess whois was a bad example.  There is nothing in the spec about automatically (and I think it should be done with the tooltip). Was just showing the difference between an op and non-op.

Comment 9

[Benedikt Pfeifer]

*** Original post on bio 574 at 2010-11-24 12:35:54 UTC ***

Bug 953721 (bio 276) should replace the nicklist with a faster list, maybe we need this one first?

Comment 10

[aleth [:aleth]]

*** Original post on bio 574 at 2012-02-11 13:29:44 UTC ***

What's left of comment #1 seems part of bug 954155 (bio 720), comment #5 is bug 953891 (bio 451), comment #7 is fixed, and the bug is not actionable anyway, so resolving as invalid.