Community
Participate
Working Groups
Currently, the IRC servers itself picks up the name change, but the userName field within org.eclipse.ecf.ui.views.ChatRoomManagerView does not. This causes the nickname highlighting feature requested in bug #148875 to not work if the user changes his or her nickname since no matches can be made.
Setting target milestone to 1.0.2. Hopefully this can be addressed on bugday and subsequently included in 1.0.2.
I am addressing this on bugday
this and bug 197329 look similar. If I am correct, it's all about to somehow populate events from IRCEventHandler attached in IRCRootContainer to proper chatrooms. A working example is Kick, that is already notified in the chatroom.
it's yours :D
Created attachment 74811 [details] patch Nickname change events go the same way as Leave and Join events. The drawback is that, it forgets user properties, so for example, when @john changes nickname to frank, actually only frank (not @frank) will show up in participants list. It could be solved if ECF maintained user IRC properties internally.
I wonder if you have had the chance to review this patch.
It's on my list to do tonight.
Hi Jacek, good patch, however, this makes some API additions so it will go into 1.1 which the stream opens for tomorrow. 1.0.2 should be released today or tomorrow. Setting the target milestone for 1.1.0, please bother me again when it's 1.1 time :)
(In reply to comment #5) > Created an attachment (id=74811) [details] > patch Jacek, could you update this patch? As you can imagine, it no longer applies cleanly (considering that a month has passed) to CVS HEAD.
Created attachment 77538 [details] updated patch
tested that it still works.
(In reply to comment #10) > Created an attachment (id=77538) [details] > updated patch I can't say that I like the call to 'handleArrived(IUser)' in the NICK_EVENT conditional clause in IRCChannelContainer given that no one is actually joining the chat room.
I was following javadoc in org.eclipse.ecf.presence.chatroom.IChatRoomParticipantListener.handleUpdated(IUser), which says "The ID of the changedParticipant (via changedParticipant.getID()) will match the ID of the previous notification handleArrived(IUser)." So I thought there should be some handleArrived before handleUpdated. What would make you happier then?
This is a bit hazardous, because afaik in IRC when user changes nickname, it's seen as previous ID totally disappeared and new ID showed up from nowhere. so in this case only handlePresenceUpdated or handleUpdated is not really accurate, because the user that changed doesn't exist now under his original ID. I quess the best would be to have a persistent ID, that doesn't change on nickname change, but that was too much for me, for bugday ;) If you have a better idea or I missed something, please let me know! We can eventually defer this bug, until better ID comes to support this case.
(In reply to comment #13) > "The ID of the changedParticipant (via changedParticipant.getID()) will match > the ID of the previous notification handleArrived(IUser)." > > So I thought there should be some handleArrived before handleUpdated. I guess that the javadocs might need to be changed slightly, I don't know. :/ I think you'd agree with me on the fact that no one has actually joined the channel, though. (In reply to comment #14) > I quess the best would be to have a persistent ID, that doesn't change on > nickname change, but that was too much for me, for bugday ;) I agree. Fixing this is not trivial at all. > We can eventually defer this bug, until better ID comes to support this case. I am going to un-bugday this as it is not for the weak of heart. ;p
> (In reply to comment #14) > > I quess the best would be to have a persistent ID, that doesn't change on > > nickname change, but that was too much for me, for bugday ;) > > I agree. Fixing this is not trivial at all. Maybe if we used USER[1] name instead of NICK[2] name as an ID, that would solve the problem. The USER name (we often see it in /whois result) is the same during whole session, even if user changes nick. It also helps to build good /ban wildcards so kicked folks can't rejoin after nick change :) I'll create a separate bug, and make this one depend on it. [1] http://www.irchelp.org/irchelp/rfc/chapter4.html#c4_1_3 [2] http://www.irchelp.org/irchelp/rfc/chapter4.html#c4_1_2
I added bug 202004
removing contributed for ip log.
Given discussion, resolving as duplicate of 202004. *** This bug has been marked as a duplicate of bug 202004 ***
