[jitsi-dev] Integration of IRC support - part 2


#1

Hi all,

It's been a while, but I have picked up development on IRC support
again. I meant to finish up a few ongoing changes, but I have been able
to make quite a few improvements since last time, among which:

* IRC 1-on-1 messaging is now implemented as Instant Messaging and the
workaround using MUC is now gone.
   (Also note that both Persistent Presence and Instant Messaging are
needed to implement this. If you only implement (Persistent) Presence
you get a "blank" chat window saying that Instant Messaging is not
supported.)
* Better management of certain events such as quitting, channel parting,
etc.
* Better support for formatting control codes.
* Support for handling some of the more common error replies.
* Simplified (and more robust) synchronization.
* Create (meta)contact, but only when requested via chat room. (So,
contacts are only created when you directly interact with them)
* Better role management (settings for voice, operator modes are stored
independently, active role computed)
* Equality of IRC accounts based on name + host + port (there exist many
IRC networks, so name alone is not enough)
and probably a lot more, mainly lots of fine tuning ...

I currently use the original SNAPSHOT-implementation of the irc-api
client library, although I have made modifications to pom.xml (Maven)
such that it creates an OSGi bundle. (Created issue requesting this to
be default: https://code.google.com/p/irc-api/issues/detail?id=15) Also,
in the mean time, there have been some improvements to irc-api too.

I'd like to work on integrating my IRC implementation into Jitsi again,
as you have suggested earlier. So, I'd like to know what it would take
to do this. (Also, the pull request is quite big, so I imagine you'd
need some time to review.)

The original pull request is still valid, although I guess Ingo and
others will probably have some feedback first. I'll try to process any
feedback within days, as well as make some of the minor changes I still
have planned.

--> Repository: https://github.com/cobratbq/jitsi (master)
--> Pull request: https://github.com/jitsi/jitsi/pull/16

I feel that this implementation is far enough along the way (in terms of
features) that we can start testing on a larger scale and create a first
stable and decent implementation.

Danny

PS: I'd like to say it is quite stable already, but since I've only
tested it for myself, you never know for sure, right? :wink:


#2

Hi all,

It's been a while, but I have picked up development on IRC support
again. I meant to finish up a few ongoing changes, but I have been able
to make quite a few improvements since last time, among which:

[features]

I currently use the original SNAPSHOT-implementation of the irc-api
client library, although I have made modifications to pom.xml (Maven)
such that it creates an OSGi bundle. (Created issue requesting this to
be default: https://code.google.com/p/irc-api/issues/detail?id=15) Also,
in the mean time, there have been some improvements to irc-api too.

If they reply soon to your request, fine. If not we just use your patch for
the binary distribution inside Jitsi.

I'd like to work on integrating my IRC implementation into Jitsi again,
as you have suggested earlier. So, I'd like to know what it would take
to do this. (Also, the pull request is quite big, so I imagine you'd
need some time to review.)

I mainly flipped through and have my usual nasty comments, among some
questions.

The original pull request is still valid, although I guess Ingo and
others will probably have some feedback first. I'll try to process any
feedback within days, as well as make some of the minor changes I still
have planned.

--> Repository: https://github.com/cobratbq/jitsi (master)
--> Pull request: https://github.com/jitsi/jitsi/pull/16

I feel that this implementation is far enough along the way (in terms of
features) that we can start testing on a larger scale and create a first
stable and decent implementation.

Unless someone else has an objection, I'm ready to merge this once you have
addressed my comments on Github.

Danny

PS: I'd like to say it is quite stable already, but since I've only
tested it for myself, you never know for sure, right? :wink:

Very true.

Thank you so much for your ongoing work on this!

Ingo

···

On 2014-07-31 06:58, Danny van Heumen wrote:


#3

Hello, Danny

Thanks for all the work -- this is really awesome!

I just added an account (on freenode) and played a bit with it. I'm running your branch merged with a recent master. Here's what I noticed:

Failures to connect (e.g. when a wrong port number is used in the account registration) are not indicated in the GUI.

I entered a name in the "Nickname" field during account registration, and it shows up in the jitsi GUI (when I enter a room, for example). However other clients show me enter as "boris" (which is my system username). This might be some misunderstanding due to my ignorance of IRC, but it's unexpected and seems weird.

Entering a room and double clicking a name results in:
     [java] 12:32:01.971 SEVERE: [20] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
      [java] java.lang.NullPointerException
      [java] at net.java.sip.communicator.impl.contactlist.MetaContactGroupImpl.findMetaContactByContact(MetaContactGroupImpl.java:569)
      [java] at net.java.sip.communicator.impl.contactlist.MetaContactListServiceImpl.findMetaContactByContact(MetaContactListServiceImpl.java:1646)
      [java] at net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:138)
      [java] at net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:114)
      [java] at net.java.sip.communicator.impl.gui.main.chat.conference.ChatRoomMemberListPanel$1.mouseClicked(ChatRoomMemberListPanel.java:117)
      [java] at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:253)
      [java] at java.awt.Component.processMouseEvent(Component.java:6417)
      [java] at javax.swing.JComponent.processMouseEvent(JComponent.java:3275)
      [java] at net.java.sip.communicator.impl.gui.main.contactlist.DefaultContactList.processMouseEvent(DefaultContactList.java:360)
      [java] at java.awt.Component.processEvent(Component.java:6179)
      [java] at java.awt.Container.processEvent(Container.java:2084)
      [java] at java.awt.Component.dispatchEventImpl(Component.java:4776)
      [java] at java.awt.Container.dispatchEventImpl(Container.java:2142)
      [java] at java.awt.Component.dispatchEvent(Component.java:4604)
      [java] at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4618)
      [java] at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4288)
      [java] at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4209)
      [java] at java.awt.Container.dispatchEventImpl(Container.java:2128)
      [java] at java.awt.Window.dispatchEventImpl(Window.java:2492)
      [java] at java.awt.Component.dispatchEvent(Component.java:4604)
      [java] at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:717)
      [java] at java.awt.EventQueue.access$400(EventQueue.java:82)
      [java] at java.awt.EventQueue$2.run(EventQueue.java:676)
      [java] at java.awt.EventQueue$2.run(EventQueue.java:674)
      [java] at java.security.AccessController.doPrivileged(Native Method)
      [java] at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:86)
      [java] at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:97)
      [java] at java.awt.EventQueue$3.run(EventQueue.java:690)
      [java] at java.awt.EventQueue$3.run(EventQueue.java:688)
      [java] at java.security.AccessController.doPrivileged(Native Method)
      [java] at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:86)
      [java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:687)
      [java] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
      [java] at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
      [java] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
      [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
      [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
      [java] at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

When someone sends me a personal message, it shows up in "recent conversations", but no tab in the chat window is opened. If I click the chat icon in "recent conversation" the tab is opened and it all works fine.

These errors are logged when I disable the account while in a room:

      [java] [ApiDaemon] ERROR com.ircclouds.irc.api.MessageDispatcherImpl -
      [java] java.lang.NullPointerException
      [java] at net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.isMe(IrcStack.java:1572)
      [java] at net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.onChannelPart(IrcStack.java:1132)
      [java] at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchVarious(MessageDispatcherImpl.java:84)
      [java] at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchTo(MessageDispatcherImpl.java:62)
      [java] at com.ircclouds.irc.api.MessageDispatcherImpl.dispatch(MessageDispatcherImpl.java:28)
      [java] at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:39)
      [java] [ApiDaemon] ERROR com.ircclouds.irc.api.MessageDispatcherImpl -
      [java] java.lang.NullPointerException
      [java] at net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.leaveChatRoom(IrcStack.java:1294)
      [java] at net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.onServerNumericMessage(IrcStack.java:1185)
      [java] at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchVarious(MessageDispatcherImpl.java:131)
      [java] at com.ircclouds.irc.api.MessageDispatcherImpl.dispatchTo(MessageDispatcherImpl.java:62)
      [java] at com.ircclouds.irc.api.MessageDispatcherImpl.dispatch(MessageDispatcherImpl.java:28)
      [java] at com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:39)
      [java] [ApiDaemon] ERROR com.ircclouds.irc.api.AbstractMessageReader - End of stream received.

Regards,
Boris

···

On 31/07/14 01:58, Danny van Heumen wrote:

I feel that this implementation is far enough along the way (in terms of
features) that we can start testing on a larger scale and create a first
stable and decent implementation.

Danny

PS: I'd like to say it is quite stable already, but since I've only
tested it for myself, you never know for sure, right? :wink:


#4

Hey Boris,

Thanks for testing.

A few of your remarks make me think that you may be running a (much)
older version of the code. Could you please check what code you are
actually running? I commit my changes to the branch 'master', so that is
most current. I give a few pointers below to check if the situation is
as expected, so that might help.

Further comments below...

I feel that this implementation is far enough along the way (in terms of
features) that we can start testing on a larger scale and create a first
stable and decent implementation.

Danny

PS: I'd like to say it is quite stable already, but since I've only
tested it for myself, you never know for sure, right? :wink:

Hello, Danny

Thanks for all the work -- this is really awesome!

I just added an account (on freenode) and played a bit with it. I'm
running your branch merged with a recent master. Here's what I noticed:

Failures to connect (e.g. when a wrong port number is used in the
account registration) are not indicated in the GUI.

Yes, this is due to Freenode (and others as well) having a number of
hosts that do not support SSL and a bunch that do. As you have probably
noticed, the check for a secure connection is on by default. This does
however limit the number of servers that you can connect to without
having to uncheck Secure Connection. (It does adjust the default port
number accordingly when you uncheck Secure Connection, so that should help.)

Did it pop up a notification message saying "Connection failed for the
following account ..."?

I entered a name in the "Nickname" field during account registration,
and it shows up in the jitsi GUI (when I enter a room, for example).
However other clients show me enter as "boris" (which is my system
username). This might be some misunderstanding due to my ignorance of
IRC, but it's unexpected and seems weird.

The nick name is always the same for all chat rooms of an IRC
connection, i.e. the nick name is determined by the account, not an
individual chat room. I am aware of this, and I suspected it to become
an issue sooner or later. I need to find a way to inform the user that a
custom nick name for this chat room is not available for IRC.

I have already taken a quick look into this. I found an OperationSet for
account details or such, which I believe I can use to "suggest" te
correct nick name. That does not enforce anything, though, so there's
still a weakness there. If you have any suggests on how we can limit
user choice at that point? (Preferrably without having to overthrow the
complete UI ...)

Entering a room and double clicking a name results in:
    [java] 12:32:01.971 SEVERE: [20]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
     [java] java.lang.NullPointerException
     [java] at
net.java.sip.communicator.impl.contactlist.MetaContactGroupImpl.findMetaContactByContact(MetaContactGroupImpl.java:569)
     [java] at
net.java.sip.communicator.impl.contactlist.MetaContactListServiceImpl.findMetaContactByContact(MetaContactListServiceImpl.java:1646)
     [java] at
net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:138)
     [java] at
net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:114)
     [java] at
net.java.sip.communicator.impl.gui.main.chat.conference.ChatRoomMemberListPanel$1.mouseClicked(ChatRoomMemberListPanel.java:117)
     [java] at
java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:253)
     [java] at
java.awt.Component.processMouseEvent(Component.java:6417)
     [java] at
javax.swing.JComponent.processMouseEvent(JComponent.java:3275)
     [java] at
net.java.sip.communicator.impl.gui.main.contactlist.DefaultContactList.processMouseEvent(DefaultContactList.java:360)
     [java] at java.awt.Component.processEvent(Component.java:6179)
     [java] at java.awt.Container.processEvent(Container.java:2084)
     [java] at
java.awt.Component.dispatchEventImpl(Component.java:4776)
     [java] at
java.awt.Container.dispatchEventImpl(Container.java:2142)
     [java] at java.awt.Component.dispatchEvent(Component.java:4604)
     [java] at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4618)
     [java] at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:4288)
     [java] at
java.awt.LightweightDispatcher.dispatchEvent(Container.java:4209)
     [java] at
java.awt.Container.dispatchEventImpl(Container.java:2128)
     [java] at java.awt.Window.dispatchEventImpl(Window.java:2492)
     [java] at java.awt.Component.dispatchEvent(Component.java:4604)
     [java] at
java.awt.EventQueue.dispatchEventImpl(EventQueue.java:717)
     [java] at java.awt.EventQueue.access$400(EventQueue.java:82)
     [java] at java.awt.EventQueue$2.run(EventQueue.java:676)
     [java] at java.awt.EventQueue$2.run(EventQueue.java:674)
     [java] at java.security.AccessController.doPrivileged(Native
Method)
     [java] at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:86)
     [java] at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:97)
     [java] at java.awt.EventQueue$3.run(EventQueue.java:690)
     [java] at java.awt.EventQueue$3.run(EventQueue.java:688)
     [java] at java.security.AccessController.doPrivileged(Native
Method)
     [java] at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:86)
     [java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:687)
     [java] at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
     [java] at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
     [java] at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
     [java] at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
     [java] at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
     [java] at
java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Hmm... I don't quite get this exception. I got this "way back" before I
implemented a correct way of creating a Contact instance when it doesn't
yet exist. So, this is somewhat unexpected.

[java] at
net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:114)
What is strange here, is that the statement before this one, on line
111, it should always get a Contact-instance. I say always, because it
will be created when it cannot be found. So, it should never be null.

Are you sure that you are running the latest version? (latest commits
should be at most a few days ago)

If so, could you trace into the statement on line 111? (call of method
room.getPrivateContactByNickname(nickname)) It should lead to code
calling "findOrCreateContactByID".

When someone sends me a personal message, it shows up in "recent
conversations", but no tab in the chat window is opened. If I click
the chat icon in "recent conversation" the tab is opened and it all
works fine.

Hmm... this also sounds familiar as behaviour from when I used the
"private conversation via chat room" workaround. Again, please confirm
that you are running current code. Just to be sure ...

These errors are logged when I disable the account while in a room:

     [java] [ApiDaemon] ERROR
com.ircclouds.irc.api.MessageDispatcherImpl -
     [java] java.lang.NullPointerException
     [java] at
net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.isMe(IrcStack.java:1572)
     [java] at
net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.onChannelPart(IrcStack.java:1132)
     [java] at
com.ircclouds.irc.api.MessageDispatcherImpl.dispatchVarious(MessageDispatcherImpl.java:84)
     [java] at
com.ircclouds.irc.api.MessageDispatcherImpl.dispatchTo(MessageDispatcherImpl.java:62)
     [java] at
com.ircclouds.irc.api.MessageDispatcherImpl.dispatch(MessageDispatcherImpl.java:28)
     [java] at
com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:39)
     [java] [ApiDaemon] ERROR
com.ircclouds.irc.api.MessageDispatcherImpl -
     [java] java.lang.NullPointerException
     [java] at
net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.leaveChatRoom(IrcStack.java:1294)
     [java] at
net.java.sip.communicator.impl.protocol.irc.IrcStack$ChatRoomListener.onServerNumericMessage(IrcStack.java:1185)
     [java] at
com.ircclouds.irc.api.MessageDispatcherImpl.dispatchVarious(MessageDispatcherImpl.java:131)
     [java] at
com.ircclouds.irc.api.MessageDispatcherImpl.dispatchTo(MessageDispatcherImpl.java:62)
     [java] at
com.ircclouds.irc.api.MessageDispatcherImpl.dispatch(MessageDispatcherImpl.java:28)
     [java] at
com.ircclouds.irc.api.AbstractApiDaemon.run(AbstractApiDaemon.java:39)
     [java] [ApiDaemon] ERROR
com.ircclouds.irc.api.AbstractMessageReader - End of stream received.

I'll look into this.

Thanks again,
Danny

···

On 08/03/2014 12:01 PM, Boris Grozev wrote:

On 31/07/14 01:58, Danny van Heumen wrote:

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Whoa, yes, I am running a very old version. Will update and let you know how it goes, sorry for the confusion.

Boris

···

On 03/08/14 17:52, Danny van Heumen wrote:

Hey Boris,

Thanks for testing.

A few of your remarks make me think that you may be running a (much)
older version of the code. Could you please check what code you are
actually running? I commit my changes to the branch 'master', so that is
most current. I give a few pointers below to check if the situation is
as expected, so that might help.


#6

Failures to connect (e.g. when a wrong port number is used in the
account registration) are not indicated in the GUI.

Yes, this is due to Freenode (and others as well) having a number of
hosts that do not support SSL and a bunch that do. As you have probably
noticed, the check for a secure connection is on by default. This does
however limit the number of servers that you can connect to without
having to uncheck Secure Connection. (It does adjust the default port
number accordingly when you uncheck Secure Connection, so that should help.)

Did it pop up a notification message saying "Connection failed for the
following account ..."?

Yes it does, all good after I updated.

I entered a name in the "Nickname" field during account registration,
and it shows up in the jitsi GUI (when I enter a room, for example).
However other clients show me enter as "boris" (which is my system
username). This might be some misunderstanding due to my ignorance of
IRC, but it's unexpected and seems weird.

The nick name is always the same for all chat rooms of an IRC
connection, i.e. the nick name is determined by the account, not an
individual chat room. I am aware of this, and I suspected it to become
an issue sooner or later. I need to find a way to inform the user that a
custom nick name for this chat room is not available for IRC.

I didn't explain what I observed well. I add an IRC account using 'zoidey' as a nickname. I expect to enter all chatrooms using 'zoidey' -- that's fine. But, when I enter a room, the IRC nickname changes to 'boris' (I never entered 'boris' anywhere, but this happens to be my OS user name).

After I enable the account I get these:
NickServ: This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.
NickServ: You are now identified for zoidey.

Then, soon after I join a room I get this again:
NickServ: This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.

This one does happen with the latest code.

Hmm... I don't quite get this exception. I got this "way back" before I
implemented a correct way of creating a Contact instance when it doesn't
yet exist. So, this is somewhat unexpected.

Doesn't happen with the latest code.

[java] at
net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:114)
What is strange here, is that the statement before this one, on line
111, it should always get a Contact-instance. I say always, because it
will be created when it cannot be found. So, it should never be null.

Are you sure that you are running the latest version? (latest commits
should be at most a few days ago)

If so, could you trace into the statement on line 111? (call of method
room.getPrivateContactByNickname(nickname)) It should lead to code
calling "findOrCreateContactByID".

When someone sends me a personal message, it shows up in "recent
conversations", but no tab in the chat window is opened. If I click
the chat icon in "recent conversation" the tab is opened and it all
works fine.

Hmm... this also sounds familiar as behaviour from when I used the
"private conversation via chat room" workaround. Again, please confirm
that you are running current code. Just to be sure ...

Doesn't happen with the latest code.

Regards,
Boris

···

On 03/08/14 17:52, Danny van Heumen wrote:


#7

Hi Boris,

Good to know that an update helps with some of the issues.

Failures to connect (e.g. when a wrong port number is used in the
account registration) are not indicated in the GUI.

Yes, this is due to Freenode (and others as well) having a number of
hosts that do not support SSL and a bunch that do. As you have probably
noticed, the check for a secure connection is on by default. This does
however limit the number of servers that you can connect to without
having to uncheck Secure Connection. (It does adjust the default port
number accordingly when you uncheck Secure Connection, so that should
help.)

Did it pop up a notification message saying "Connection failed for the
following account ..."?

Yes it does, all good after I updated.

Great.

I entered a name in the "Nickname" field during account registration,
and it shows up in the jitsi GUI (when I enter a room, for example).
However other clients show me enter as "boris" (which is my system
username). This might be some misunderstanding due to my ignorance of
IRC, but it's unexpected and seems weird.

The nick name is always the same for all chat rooms of an IRC
connection, i.e. the nick name is determined by the account, not an
individual chat room. I am aware of this, and I suspected it to become
an issue sooner or later. I need to find a way to inform the user that a
custom nick name for this chat room is not available for IRC.

I didn't explain what I observed well. I add an IRC account using
'zoidey' as a nickname. I expect to enter all chatrooms using 'zoidey'
-- that's fine. But, when I enter a room, the IRC nickname changes to
'boris' (I never entered 'boris' anywhere, but this happens to be my
OS user name).

After I enable the account I get these:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.
NickServ: You are now identified for zoidey.

Then, soon after I join a room I get this again:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.

Hmmm... this may be due to the chat room issueing a nick change. It
could be that the chat room has stored another nick and setting that
upon joining. Could you remove the chat room and re-add it, but when you
do and it asks for the details such as the nick name, don't set a
different nick name.

I believe that if you do that, then it shouldn't change your nick. In my
tests I never see my OS user name occur. I don't think it gets read
anywhere.

This one does happen with the latest code.

Hmm... I don't quite get this exception. I got this "way back" before I
implemented a correct way of creating a Contact instance when it doesn't
yet exist. So, this is somewhat unexpected.

Doesn't happen with the latest code.

Good.

[java] at
net.java.sip.communicator.impl.gui.main.chat.ChatWindowManager.openPrivateChatForChatRoomMember(ChatWindowManager.java:114)

What is strange here, is that the statement before this one, on line
111, it should always get a Contact-instance. I say always, because it
will be created when it cannot be found. So, it should never be null.

Are you sure that you are running the latest version? (latest commits
should be at most a few days ago)

If so, could you trace into the statement on line 111? (call of method
room.getPrivateContactByNickname(nickname)) It should lead to code
calling "findOrCreateContactByID".

When someone sends me a personal message, it shows up in "recent
conversations", but no tab in the chat window is opened. If I click
the chat icon in "recent conversation" the tab is opened and it all
works fine.

Hmm... this also sounds familiar as behaviour from when I used the
"private conversation via chat room" workaround. Again, please confirm
that you are running current code. Just to be sure ...

Doesn't happen with the latest code.

Good.

Regards,
Danny

···

On 08/03/2014 07:53 PM, Boris Grozev wrote:

On 03/08/14 17:52, Danny van Heumen wrote:

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

You are right, 'boris' was written (hidden under 'more') in the chat room menu, and the OS name is a red hairing.

So, everything now works beautifully!

Boris

···

On 03/08/14 21:02, Danny van Heumen wrote:

Hi Boris,

Good to know that an update helps with some of the issues.

On 08/03/2014 07:53 PM, Boris Grozev wrote:

On 03/08/14 17:52, Danny van Heumen wrote:

Failures to connect (e.g. when a wrong port number is used in the
account registration) are not indicated in the GUI.

Yes, this is due to Freenode (and others as well) having a number of
hosts that do not support SSL and a bunch that do. As you have probably
noticed, the check for a secure connection is on by default. This does
however limit the number of servers that you can connect to without
having to uncheck Secure Connection. (It does adjust the default port
number accordingly when you uncheck Secure Connection, so that should
help.)

Did it pop up a notification message saying "Connection failed for the
following account ..."?

Yes it does, all good after I updated.

Great.

I entered a name in the "Nickname" field during account registration,
and it shows up in the jitsi GUI (when I enter a room, for example).
However other clients show me enter as "boris" (which is my system
username). This might be some misunderstanding due to my ignorance of
IRC, but it's unexpected and seems weird.

The nick name is always the same for all chat rooms of an IRC
connection, i.e. the nick name is determined by the account, not an
individual chat room. I am aware of this, and I suspected it to become
an issue sooner or later. I need to find a way to inform the user that a
custom nick name for this chat room is not available for IRC.

I didn't explain what I observed well. I add an IRC account using
'zoidey' as a nickname. I expect to enter all chatrooms using 'zoidey'
-- that's fine. But, when I enter a room, the IRC nickname changes to
'boris' (I never entered 'boris' anywhere, but this happens to be my
OS user name).

After I enable the account I get these:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.
NickServ: You are now identified for zoidey.

Then, soon after I join a room I get this again:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.

Hmmm... this may be due to the chat room issueing a nick change. It
could be that the chat room has stored another nick and setting that
upon joining. Could you remove the chat room and re-add it, but when you
do and it asks for the details such as the nick name, don't set a
different nick name.

I believe that if you do that, then it shouldn't change your nick. In my
tests I never see my OS user name occur. I don't think it gets read
anywhere.


#9

Hi Boris,

Hi Boris,

Good to know that an update helps with some of the issues.

Failures to connect (e.g. when a wrong port number is used in the
account registration) are not indicated in the GUI.

Yes, this is due to Freenode (and others as well) having a number of
hosts that do not support SSL and a bunch that do. As you have
probably
noticed, the check for a secure connection is on by default. This does
however limit the number of servers that you can connect to without
having to uncheck Secure Connection. (It does adjust the default port
number accordingly when you uncheck Secure Connection, so that should
help.)

Did it pop up a notification message saying "Connection failed for the
following account ..."?

Yes it does, all good after I updated.

Great.

I entered a name in the "Nickname" field during account registration,
and it shows up in the jitsi GUI (when I enter a room, for example).
However other clients show me enter as "boris" (which is my system
username). This might be some misunderstanding due to my ignorance of
IRC, but it's unexpected and seems weird.

The nick name is always the same for all chat rooms of an IRC
connection, i.e. the nick name is determined by the account, not an
individual chat room. I am aware of this, and I suspected it to become
an issue sooner or later. I need to find a way to inform the user
that a
custom nick name for this chat room is not available for IRC.

I didn't explain what I observed well. I add an IRC account using
'zoidey' as a nickname. I expect to enter all chatrooms using 'zoidey'
-- that's fine. But, when I enter a room, the IRC nickname changes to
'boris' (I never entered 'boris' anywhere, but this happens to be my
OS user name).

After I enable the account I get these:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.
NickServ: You are now identified for zoidey.

Then, soon after I join a room I get this again:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.

Hmmm... this may be due to the chat room issueing a nick change. It
could be that the chat room has stored another nick and setting that
upon joining. Could you remove the chat room and re-add it, but when you
do and it asks for the details such as the nick name, don't set a
different nick name.

I believe that if you do that, then it shouldn't change your nick. In my
tests I never see my OS user name occur. I don't think it gets read
anywhere.

You are right, 'boris' was written (hidden under 'more') in the chat
room menu, and the OS name is a red hairing.

Okay, that's good. Still, you have a valid point. The "nick name" per
chat room will cause more trouble. I'll add that to the list.

So, everything now works beautifully!

:slight_smile:

Danny

···

On 08/03/2014 08:13 PM, Boris Grozev wrote:

On 03/08/14 21:02, Danny van Heumen wrote:

On 08/03/2014 07:53 PM, Boris Grozev wrote:

On 03/08/14 17:52, Danny van Heumen wrote:

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Hi Boris,

From now on making nick changes via the chat room configuration is not

supported anymore. As you discovered yourself, it is confusing and
doesn't really work as advertised.

From now on, the only way you can change your nick name, is by modifying

the IRC account.

Thanks again for testing.

Kind regards,
Danny

···

On 08/03/2014 08:13 PM, Boris Grozev wrote:

On 03/08/14 21:02, Danny van Heumen wrote:

Hi Boris,

Good to know that an update helps with some of the issues.

On 08/03/2014 07:53 PM, Boris Grozev wrote:

On 03/08/14 17:52, Danny van Heumen wrote:

Failures to connect (e.g. when a wrong port number is used in the
account registration) are not indicated in the GUI.

Yes, this is due to Freenode (and others as well) having a number of
hosts that do not support SSL and a bunch that do. As you have
probably
noticed, the check for a secure connection is on by default. This does
however limit the number of servers that you can connect to without
having to uncheck Secure Connection. (It does adjust the default port
number accordingly when you uncheck Secure Connection, so that should
help.)

Did it pop up a notification message saying "Connection failed for the
following account ..."?

Yes it does, all good after I updated.

Great.

I entered a name in the "Nickname" field during account registration,
and it shows up in the jitsi GUI (when I enter a room, for example).
However other clients show me enter as "boris" (which is my system
username). This might be some misunderstanding due to my ignorance of
IRC, but it's unexpected and seems weird.

The nick name is always the same for all chat rooms of an IRC
connection, i.e. the nick name is determined by the account, not an
individual chat room. I am aware of this, and I suspected it to become
an issue sooner or later. I need to find a way to inform the user
that a
custom nick name for this chat room is not available for IRC.

I didn't explain what I observed well. I add an IRC account using
'zoidey' as a nickname. I expect to enter all chatrooms using 'zoidey'
-- that's fine. But, when I enter a room, the IRC nickname changes to
'boris' (I never entered 'boris' anywhere, but this happens to be my
OS user name).

After I enable the account I get these:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.
NickServ: You are now identified for zoidey.

Then, soon after I join a room I get this again:
NickServ: This nickname is registered. Please choose a different
nickname, or identify via /msg NickServ identify <password>.

Hmmm... this may be due to the chat room issueing a nick change. It
could be that the chat room has stored another nick and setting that
upon joining. Could you remove the chat room and re-add it, but when you
do and it asks for the details such as the nick name, don't set a
different nick name.

I believe that if you do that, then it shouldn't change your nick. In my
tests I never see my OS user name occur. I don't think it gets read
anywhere.

You are right, 'boris' was written (hidden under 'more') in the chat
room menu, and the OS name is a red hairing.

So, everything now works beautifully!

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev