first great work! Thanks for the irc provider!
Everything is working fine, I just have some improvements in mind.
First after I created my account, I tried adding a chat room, but
clicking on Join was doing nothing. I had to go to the logs to realize
that I was entering the room without the # sign.
java.lang.IllegalArgumentException: invalid channel prefix: j
at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.verifyName(ChatRoomIrcImpl.java:173)

Maybe we can let this exception go to the UI and show an error text in
"Add chat room" dialog, like "invalid channel prefix: j (maybe missing
#)" or something similar and meaningful for the user.

The second one that bothers me is the NickServ in not in contact list.
Didn't we have a special system chat room(chat room without the
members list)? If we have one, the NickServ can be shown in Chat Rooms
list, WDYT?

Anyway, thanks and great work! And thanks Ingo for taking care of it
and merging it!

Regards
damencho

P.S. Can you point me to the sources of the IRC stack, maybe I have
missed that email from the mailinglist Will need to add them to the
debian source package.

one more, which I'm not sure was it there before irc when I receive
a new message in a room, and the tab is opened, but is not the
selected one, the tab is selected. Which of course has and a security
problem, you may send a message(or a part of it) to wrong tab, the way
it happened to me.

first great work! Thanks for the irc provider!
Everything is working fine, I just have some improvements in mind.
First after I created my account, I tried adding a chat room, but
clicking on Join was doing nothing. I had to go to the logs to realize
that I was entering the room without the # sign.
java.lang.IllegalArgumentException: invalid channel prefix: j
at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.verifyName(ChatRoomIrcImpl.java:173)

Maybe we can let this exception go to the UI and show an error text in
"Add chat room" dialog, like "invalid channel prefix: j (maybe missing
#)" or something similar and meaningful for the user.

The second one that bothers me is the NickServ in not in contact list.
Didn't we have a special system chat room(chat room without the
members list)? If we have one, the NickServ can be shown in Chat Rooms
list, WDYT?

Anyway, thanks and great work! And thanks Ingo for taking care of it
and merging it!

Regards
damencho

P.S. Can you point me to the sources of the IRC stack, maybe I have
missed that email from the mailinglist Will need to add them to the
debian source package.

first great work! Thanks for the irc provider! Everything is working
fine, I just have some improvements in mind. First after I created my
account, I tried adding a chat room, but clicking on Join was doing
nothing. I had to go to the logs to realize that I was entering the room
without the # sign. java.lang.IllegalArgumentException: invalid channel
prefix: j at
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.verifyName(Cha
tRo omIrcImpl.java:173)

Maybe we can let this exception go to the UI and show an error text in
"Add chat room" dialog, like "invalid channel prefix: j (maybe missing
#)" or something similar and meaningful for the user.

Wouldn't it be best if both (with and without #) just worked by
automatically adding the # if the user didn't enter it?

The second one that bothers me is the NickServ in not in contact list.
Didn't we have a special system chat room(chat room without the
members list)? If we have one, the NickServ can be shown in Chat Rooms
list, WDYT?

Anyway, thanks and great work! And thanks Ingo for taking care of it
and merging it!

Regards
damencho

P.S. Can you point me to the sources of the IRC stack, maybe I have
missed that email from the mailinglist Will need to add them to the
debian source package.

one more, which I'm not sure was it there before irc when I receive
a new message in a room, and the tab is opened, but is not the
selected one, the tab is selected. Which of course has and a security
problem, you may send a message(or a part of it) to wrong tab, the way
it happened to me.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

Regards
damencho

Hi Danny,

first great work! Thanks for the irc provider!
Everything is working fine, I just have some improvements in mind.

Thanks

First after I created my account, I tried adding a chat room, but
clicking on Join was doing nothing. I had to go to the logs to realize
that I was entering the room without the # sign.
java.lang.IllegalArgumentException: invalid channel prefix: j
at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.verifyName(ChatRoomIrcImpl.java:173)

Yeah ... very recent change because it came to me that it was more
appropriate to check the name in the ChatRoom implementation. Will fix
that ... obvious mistake.

Maybe we can let this exception go to the UI and show an error text in
"Add chat room" dialog, like "invalid channel prefix: j (maybe missing
#)" or something similar and meaningful for the user.

I'll have to see how a message looks. I can also "assume" the # and add
it if it's missing. Although there are 2 channel symbols: # and & IIRC.
The second isn't often used. So I'm thinking of making # the implicitly
added prefix and & must be typed to be used.

The second one that bothers me is the NickServ in not in contact list.
Didn't we have a special system chat room(chat room without the
members list)? If we have one, the NickServ can be shown in Chat Rooms
list, WDYT?

Yeah, I do remember seeing stuff about the system room. The problem here
is mainly that NickServ (and ChanServ for that matter) is not the actual
server itself. This is interaction with a "user" which is actually a bot
hosted by the IRC network server.

I need to check if I can get some information beforehand to tell that
these are the bots. ChanServ, for example, sends you some info if you
join particular channels, for example channel rules and if so that a
channel is logged and such.

first great work! Thanks for the irc provider! Everything is working
fine, I just have some improvements in mind. First after I created my
account, I tried adding a chat room, but clicking on Join was doing
nothing. I had to go to the logs to realize that I was entering the room
without the # sign. java.lang.IllegalArgumentException: invalid channel
prefix: j at
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.verifyName(Cha
tRo omIrcImpl.java:173)

Maybe we can let this exception go to the UI and show an error text in
"Add chat room" dialog, like "invalid channel prefix: j (maybe missing
#)" or something similar and meaningful for the user.

Wouldn't it be best if both (with and without #) just worked by
automatically adding the # if the user didn't enter it?

Looking into that. (see reply to Damian)

The second one that bothers me is the NickServ in not in contact list.
Didn't we have a special system chat room(chat room without the
members list)? If we have one, the NickServ can be shown in Chat Rooms
list, WDYT?

Anyway, thanks and great work! And thanks Ingo for taking care of it
and merging it!

Regards
damencho

P.S. Can you point me to the sources of the IRC stack, maybe I have
missed that email from the mailinglist Will need to add them to the
debian source package.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

I have been able to fix 2 issues by doing a system suspend and then
waking it up again. However, I have not been able to reproduce the
off-by-one error. This is probably a bug in the irc-api client library,
so when I get to reproduce it, I will report this upstream. If you
happen to be able to reproduce this reliably, let me know.

Kind regards,
Danny

···

On 08/27/2014 10:06 PM, Boris Grozev wrote:

On 27/08/14 22:58, Danny van Heumen wrote:

This definitely looks like an off-by-one bug. We can be pretty certain
that this was supposed to be NickServ too. I'm going to keep an eye out
for this, although I've never encountered this before.

What was the reason for the (re)connect. Just a different server or did
something go wrong? (Maybe lost connection or such ..)

I closed my laptop, opened it about 2 hours later and connected to a
different network.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

Does this clears, what I meant?

Hmm... so basically, focus changes whenever a message arrives at the#jitsi chat room ... Do you know if you were mentioned in the message?
(i.e. your nick name in the message such that it gets highlighted?) I
know that Hristo did some modifications to chat room behaviour, also to
prevent chat room pop-ups on every single message that gets sent. So,
maybe it focuses when you are mentioned.

The reason I ask this is that for me, I can have 10 chat rooms open, but
I (virtually) never get tab switches, so I'm actually quite surprised. I
myself am working on XFCE (Linux) at the moment, so maybe this behaviour
is different in different windowing environments. The other situation I
can think of is that these tab switches only happen if the active tab is
of a different protocol. I'll have to investigate it as I currently
don't have clue :-P.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

Yesterday evening I've been playing around with Jitsi + IRC on Windows.
I've been trying to reproduce what you describe above. I haven't been
able to find a single behaviour as you describe. I've tried the following:
1. Open up a bunch of chat rooms, in order to try and produce the
tab-switching behaviour. I haven't been able to. The tab that I click is
and stays active and focus is on that tab only.
2. Having the chat rooms open, select the tab of one chat room and then
send a message on another. - No switch or focus change at all.
3. Having the chat rooms open, select the tab of one chat room, then
mention "myself" via another IRC client on the other chat room. - No
focus switch at all.
4. Start typing a message in a chat window of another account and then
switch tabs. Message stays with original tab, switch of tab starts with
empty chat input box. ( ... and now that I reread the sentence, you say
you accidentally continue to type in the other chat input box ... okay
that explains, I misread the first time there ...)

As I've said before .. the thing that I know of that is most closely
related to this is probably Hristo's change in when chat rooms decide to
pop up, i.e. not every message in a chat room will take focus. Could it
be that you're using an old configuration that behaves differently than
is now standard? (If this is even configurable ... I'm not sure.)

And I'm curious on what OS you have been trying this out? (I've tried to
reproduce on Linux and Windows but so far no luck ...)

Let me know if you continue to have this problem and maybe if you have
some extra information that would be great

1.1 shrink whitespace to make list of people in channel use less space (currently between the names theres a lot of whitespace, making that list somewhat inefficient)
1.2 use color codes to show away or present state of people in IRC channel (currently only grey and dark grey with star for mods)

2 IRC features

2.1 allow auto away setting (either add a separate option, but I’d rather suggest to adapt the existing jitsi auto-away time and use this for IRC as well)
2.2 allow hiding join / leave notices

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

Does this clears, what I meant?

Hmm... so basically, focus changes whenever a message arrives at the#jitsi chat room ... Do you know if you were mentioned in the message?
(i.e. your nick name in the message such that it gets highlighted?) I
know that Hristo did some modifications to chat room behaviour, also to
prevent chat room pop-ups on every single message that gets sent. So,
maybe it focuses when you are mentioned.

The reason I ask this is that for me, I can have 10 chat rooms open, but
I (virtually) never get tab switches, so I'm actually quite surprised. I
myself am working on XFCE (Linux) at the moment, so maybe this behaviour
is different in different windowing environments. The other situation I
can think of is that these tab switches only happen if the active tab is
of a different protocol. I'll have to investigate it as I currently
don't have clue :-P.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

...

As I've said before .. the thing that I know of that is most closely
related to this is probably Hristo's change in when chat rooms decide to
pop up, i.e. not every message in a chat room will take focus. Could it
be that you're using an old configuration that behaves differently than
is now standard? (If this is even configurable ... I'm not sure.)

...

I just noticed where you can configure this behaviour. If you
right-click a chat room, the bottom option says something like:
"Open this room automatically when ...
<some-answer>"
The available options (for me) are:
* Open on activity
* Open on message only
* Open on important messages only

You probably have either the top one or the middle one set.
... although I can't imagine even the top one giving you any trouble on#jitsi

Nice suggestion. I will keep this in mind, though this affects more
than just IRC, so we’ll probably don’t want to go the one very thin
line that IRC clients often use.
I am not sure if a server informs clients when a user sets ‘away’
status. I’ll keep it in mind though.
This is already on my list of things to do.
Will do. Indeed sometimes these system message just push away normal
conversation. I’ll have to see where in the UI I can best integrate
this (or connect to an existing configuration entry).
Thanks for your feedback,
Danny

···

Hi Foss,

Response in line ...
On 08/16/2014 01:14 PM, Foss wrote:

First observations, feel free ot proceed as you like (tickets, PR, …)
1 IRC channel UI
1.1 shrink whitespace to make list of people in channel use less space (currently between the names theres a lot of whitespace, making that list somewhat inefficient)

1.2 use color codes to show away or present state of people in IRC channel (currently only grey and dark grey with star for mods)

2 IRC features
2.1 allow auto away setting (either add a separate option, but I’d rather suggest to adapt the existing jitsi auto-away time and use this for IRC as well)

2.2 allow hiding join / leave notices

Am 14.08.2014 um 23:31 schrieb Danny van Heumen :

Hi,
On 08/14/2014 10:27 PM, Damian Minkov wrote:

Hi,
On Thu, Aug 14, 2014 at 8:21 PM, Danny van Heumen
wrote:

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,
#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows
#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.
Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.
Does this clears, what I meant?

Hmm... so basically, focus changes whenever a message arrives at the
#jitsi chat room ... Do you know if you were mentioned in the message?
(i.e. your nick name in the message such that it gets highlighted?) I
know that Hristo did some modifications to chat room behaviour, also to
prevent chat room pop-ups on every single message that gets sent. So,
maybe it focuses when you are mentioned.
The reason I ask this is that for me, I can have 10 chat rooms open, but
I (virtually) never get tab switches, so I'm actually quite surprised. I
myself am working on XFCE (Linux) at the moment, so maybe this behaviour
is different in different windowing environments. The other situation I
can think of is that these tab switches only happen if the active tab is
of a different protocol. I'll have to investigate it as I currently
don't have clue :-P.
Kind regards,
Danny

I've just tested it and its not only problem with IRC, it is a problem
with all chat rooms.
If you have selected the first or the second option for a chat room
and you receive a message the tab is automatically focused (switching
the tab) if you are on a different tab.
I think the behavior should be the same as when using normal chat, the
title gets red with (N) where N is the number of messages.
I think I've corrected it with: 29953c199f846bb485ada88dec0a427dfe213f52
you can try it.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

...

As I've said before .. the thing that I know of that is most closely
related to this is probably Hristo's change in when chat rooms decide to
pop up, i.e. not every message in a chat room will take focus. Could it
be that you're using an old configuration that behaves differently than
is now standard? (If this is even configurable ... I'm not sure.)

...

I just noticed where you can configure this behaviour. If you
right-click a chat room, the bottom option says something like:
"Open this room automatically when ...
<some-answer>"
The available options (for me) are:
* Open on activity
* Open on message only
* Open on important messages only

You probably have either the top one or the middle one set.
... although I can't imagine even the top one giving you any trouble on#jitsi

Indeed, it works for me and this is much nicer behaviour.
I have modified the default behaviour to MUCService.OPEN_ON_MESSAGE.
This means that by default the chat room will open upon receiving a new
message. (Or highlight if it is already open, as you just fixed.)

I think it makes more sense to receive messages on joined chat rooms and
for those occasions where a chat room is very high traffic and you are
only very occasionally interested, you can set another auto-join option
as desired. (Or you could not join of course.)

I've also created a constant for the default behaviour, so we can easily
change that in the future.

Danny

···

On 08/21/2014 12:09 PM, Damian Minkov wrote:

Hi,

I've just tested it and its not only problem with IRC, it is a problem
with all chat rooms.
If you have selected the first or the second option for a chat room
and you receive a message the tab is automatically focused (switching
the tab) if you are on a different tab.
I think the behavior should be the same as when using normal chat, the
title gets red with (N) where N is the number of messages.
I think I've corrected it with: 29953c199f846bb485ada88dec0a427dfe213f52
you can try it.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

...

As I've said before .. the thing that I know of that is most closely
related to this is probably Hristo's change in when chat rooms decide to
pop up, i.e. not every message in a chat room will take focus. Could it
be that you're using an old configuration that behaves differently than
is now standard? (If this is even configurable ... I'm not sure.)

...

I just noticed where you can configure this behaviour. If you
right-click a chat room, the bottom option says something like:
"Open this room automatically when ...
<some-answer>"
The available options (for me) are:
* Open on activity
* Open on message only
* Open on important messages only

You probably have either the top one or the middle one set.
... although I can't imagine even the top one giving you any trouble on#jitsi

These requests are still open. How are you planning to address those? I’m just asking because if they can not be addressed atm that is fine, but then maybe we should create tickets? Or is the bug tracker just a graveyard?

1 IRC channel UI
1.1 shrink whitespace to make list of people in channel use less space (currently between the names theres a lot of whitespace, making that list somewhat inefficient)
1.2 use color codes to show away or present state of people in IRC channel (currently only grey and dark grey with star for mods)
-> did some testing with Danny and it’s only possible to request the status at the beginning. status changes do not get transported in the IRC protocol (which is why people instead change their nicknames to nickname_away). Nonetheless this could be done with red and green (as in adium) upon first connection.
NEW 1.3 when joining an IRC channel via top menu (OSX) File > Add chat room, the „Join“ button should already be in focus. So that once a roomname has been entered, the user only has to press the enter button. currently he either has to tab three times or use the mouse. both very inefficient. adium does this correctly if you want a reference.

2 IRC features
2.2 allow hiding join / leave notices

3 bugs
I get flakey behavior for auto-joining channel in my contact list. I’m still trying to find a reproduce pattern. But have not been able to really do so.
what I get is:
3.1 "Error - The chatroom is already joined“ when having chat room on „Auto-join“, I’m correctly connected to the chat room but on most startups I see that error msg
3.2 „auto-join“ not working at all. while playing with 3.1 I am now seeing the case in which on jitsi startup none of my 2 auto-join IRC channels is connected, nor do I see any error.
3.3 when having two channels on „auto-join“ only the first is connected (if at all it is connected that is). If it is connected I always see the error message from 3.1. the second IRC channel seems to be ignored.

Hm, seems there was issues again with my account setup. Now set to use default port instead of 6697 and back to behavior 3.3 and 3.1. 3.2 does no longer happen.

Hm another restart same settings and back to 3.2, despite the IRC account saying it is online.

This def. needs to be stabilized. Danny if you need more info or want to test this out with me, just ping me.

Indeed, it works for me and this is much nicer behaviour.
I have modified the default behaviour to MUCService.OPEN_ON_MESSAGE.
This means that by default the chat room will open upon receiving a new
message. (Or highlight if it is already open, as you just fixed.)

I think it makes more sense to receive messages on joined chat rooms and
for those occasions where a chat room is very high traffic and you are
only very occasionally interested, you can set another auto-join option
as desired. (Or you could not join of course.)

I've also created a constant for the default behaviour, so we can easily
change that in the future.

Danny

On 08/21/2014 12:09 PM, Damian Minkov wrote:

Hi,

I've just tested it and its not only problem with IRC, it is a problem
with all chat rooms.
If you have selected the first or the second option for a chat room
and you receive a message the tab is automatically focused (switching
the tab) if you are on a different tab.
I think the behavior should be the same as when using normal chat, the
title gets red with (N) where N is the number of messages.
I think I've corrected it with: 29953c199f846bb485ada88dec0a427dfe213f52
you can try it.

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.

Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

...

As I've said before .. the thing that I know of that is most closely
related to this is probably Hristo's change in when chat rooms decide to
pop up, i.e. not every message in a chat room will take focus. Could it
be that you're using an old configuration that behaves differently than
is now standard? (If this is even configurable ... I'm not sure.)

...

I just noticed where you can configure this behaviour. If you
right-click a chat room, the bottom option says something like:
"Open this room automatically when ...
<some-answer>"
The available options (for me) are:
* Open on activity
* Open on message only
* Open on important messages only

You probably have either the top one or the middle one set.
... although I can't imagine even the top one giving you any trouble on#jitsi

primarily keep track of the emails being sent, but it’s good to
have a list to check once in a while. I’ll just need to think of
updating it when I fix an issue.

About 1.3, I think that there's something else at the root of

this. On Windows I noticed that the button was still disabled,
even though I had selected an account and entered a chat room
name. Maybe you are affected by this too, in some different way.
It’s a weird deviation in behaviour, though, in Win vs. OSX vs.
Linux.

About the auto-join behaviour. That is driven by Jitsi and I

haven’t extensively tested its behaviour together with IRC. So I
could have slipped up in the point where I report the connection
as initiated or such. I need to check that.

About your account settings. In case of Freenode, you should keep

in mind that you:

- Either use chat.freenode.net with port 6697 (more or less)

default for secure connection with secure connection ENABLED.

- Or use any freenode-addres, such as irc.freenode.net, with port

6667 (default) with secure connection DISABLED.

- Or just check the network's website for the correct address and

SSL capabilities (<-- works for any network)

If you still have troubles, than I think we need to check the

logging, because then I’m out of ideas on where it can go wrong.

Danny
On 08/22/2014 11:38 AM, Foss wrote:

These requests are still open. How are you planning to address those? I’m just asking because if they can not be addressed atm that is fine, but then maybe we should create tickets? Or is the bug tracker just a graveyard?
1 IRC channel UI
1.1 shrink whitespace to make list of people in channel use less space (currently between the names theres a lot of whitespace, making that list somewhat inefficient)
1.2 use color codes to show away or present state of people in IRC channel (currently only grey and dark grey with star for mods)
-> did some testing with Danny and it’s only possible to request the status at the beginning. status changes do not get transported in the IRC protocol (which is why people instead change their nicknames to nickname_away). Nonetheless this could be done with red and green (as in adium) upon first connection.
NEW 1.3 when joining an IRC channel via top menu (OSX) File > Add chat room, the „Join“ button should already be in focus. So that once a roomname has been entered, the user only has to press the enter button. currently he either has to tab three times or use the mouse. both very inefficient. adium does this correctly if you want a reference.
2 IRC features
2.2 allow hiding join / leave notices
3 bugs
I get flakey behavior for auto-joining channel in my contact list. I’m still trying to find a reproduce pattern. But have not been able to really do so.
what I get is:
3.1 "Error - The chatroom is already joined“ when having chat room on „Auto-join“, I’m correctly connected to the chat room but on most startups I see that error msg
3.2 „auto-join“ not working at all. while playing with 3.1 I am now seeing the case in which on jitsi startup none of my 2 auto-join IRC channels is connected, nor do I see any error.
3.3 when having two channels on „auto-join“ only the first is connected (if at all it is connected that is). If it is connected I always see the error message from 3.1. the second IRC channel seems to be ignored.
Hm, seems there was issues again with my account setup. Now set to use default port instead of 6697 and back to behavior 3.3 and 3.1. 3.2 does no longer happen.
Hm another restart same settings and back to 3.2, despite the IRC account saying it is online.
This def. needs to be stabilized. Danny if you need more info or want to test this out with me, just ping me.
Hope this is useful.
Regards
Am 21.08.2014 um 23:12 schrieb Danny van Heumen :

Hi,
Indeed, it works for me and this is much nicer behaviour.
I have modified the default behaviour to MUCService.OPEN_ON_MESSAGE.
This means that by default the chat room will open upon receiving a new
message. (Or highlight if it is already open, as you just fixed.)
I think it makes more sense to receive messages on joined chat rooms and
for those occasions where a chat room is very high traffic and you are
only very occasionally interested, you can set another auto-join option
as desired. (Or you could not join of course.)
I've also created a constant for the default behaviour, so we can easily
change that in the future.
Danny
On 08/21/2014 12:09 PM, Damian Minkov wrote:

Hi,
I've just tested it and its not only problem with IRC, it is a problem
with all chat rooms.
If you have selected the first or the second option for a chat room
and you receive a message the tab is automatically focused (switching
the tab) if you are on a different tab.
I think the behavior should be the same as when using normal chat, the
title gets red with (N) where N is the number of messages.
I think I've corrected it with: 29953c199f846bb485ada88dec0a427dfe213f52
you can try it.
Regards
damencho
On Wed, Aug 20, 2014 at 11:36 PM, Danny van Heumen
wrote:

Hi damencho,
On 08/20/2014 09:24 PM, Danny van Heumen wrote:

Hi damencho,
On 08/14/2014 10:27 PM, Damian Minkov wrote:

Hi,
On Thu, Aug 14, 2014 at 8:21 PM, Danny van Heumen
wrote:

So, let me see if I inderstand you ... you have, say 3 chatrooms #a, #b,
#c. Room #b is selected but, say, you've minimized the chat window. Then
if you get a message on #a, when you unminimize the room, it still shows
#b? ... somehow I think I'm missing something here ... because if you
see the message in the chat window tab, that is also the tab that is
selected.
Do you mean via the notification pop-up, maybe?

So the situation is the following:
I have one ChatWindow and 3 tabs, one chatting with Emil, one chatting
with Yana and one #jitsi. While writing a message to Yana, someone
sends a message in #jitsi, and #jitsi tab becomes the selected (Yana's
chat tab is no longer the selected) and as I was writing to Yana but
the tab changed the end of the message is written in the #jitsi tab.

...
As I've said before .. the thing that I know of that is most closely
related to this is probably Hristo's change in when chat rooms decide to
pop up, i.e. not every message in a chat room will take focus. Could it
be that you're using an old configuration that behaves differently than
is now standard? (If this is even configurable ... I'm not sure.)
...

I just noticed where you can configure this behaviour. If you
right-click a chat room, the bottom option says something like:
"Open this room automatically when ...
<some-answer>"
The available options (for me) are:
* Open on activity
* Open on message only
* Open on important messages only
You probably have either the top one or the middle one set.
... although I can't imagine even the top one giving you any trouble on
#jitsi ;-)
Danny
_______________________________________________
dev mailing list
Unsubscribe instructions and other list options: