[jitsi-dev] IRC implementation ready for a larger audience (?)


#1

Hi,

I think that the IRC implementation is (almost) at a stage now, where it
would be nice to have a larger audience look at it and use it. It is
still rather far from a complete implementation, especially if you
consider all the additional channel modes and such that have been
introduced by individual servers.

What is currently possible is the following:
- Create (and edit) IRC accounts. (Inherited from the old
implementation, just added a few tweaks.)
- Support for secure connections (minimal UI tweaks in order to indicate
a secure connection)
- Join chatrooms
- Send and receive messages
- Receive private messages.
- Send private messages (although currently via a workaround by typing
'/msg <user> <message>'. Once you receive a message, a new
(non-persistent) chat room emerges.)
- Correctly handle nick changes, users joining, leaving, being kicked,
quitting. ==> Hence the list of chat room members should be current at
all times.
- Listing available chat rooms on a server. (Queries the list once, then
stores the result.)
- A few channel mode changes are recognized, currently: member status
changes (default, voiced, opped, owner) for both yourself and fellow
chat room members.

Now what's still to be done: (A lot ...)
- Correct detection of channel forwarding
- Correct detection of some join failures
- Other channel mode changes.
- Private messaging via UI (double clicking chat room member)
- IRC formatting (which also fixes an issue that corrupts a specific
channel's history file when control characters are sent and stored.)
- DCC support
- Lots of stuff ...

Note that because of some (mostly minor) issues I encountered in the IRC
library, some change is going on there too. So this library, too, is in
motion.

All in all, I would like to work towards a stable though somewhat
minimal working IRC implementation and improve from there. And for that
I would like to ask for help from some other adventurous souls who are
willing to spend some time using and testing the implementation and who
will report any bugs, stack traces, etc. they encounter.

Anyone willing to help?
Anyone with suggestions on how we can best approach this? I.e.
- merge into nightly?
- keep separate repo that is up to date with nightly?
- create separate bundles to add? (can those be added easily to an
existing installation?)

I'm curious to all of your thoughts and responses!

Danny


#2

Hey Danny,

Hi,

I think that the IRC implementation is (almost) at a stage now,

Youhouuu! :slight_smile:
Very nice! Looking forward to the pull request.

where it
would be nice to have a larger audience look at it and use it. It is
still rather far from a complete implementation, especially if you
consider all the additional channel modes and such that have been
introduced by individual servers.

What is currently possible is the following:
- Create (and edit) IRC accounts. (Inherited from the old
implementation, just added a few tweaks.)
- Support for secure connections (minimal UI tweaks in order to indicate
a secure connection)
- Join chatrooms
- Send and receive messages
- Receive private messages.
- Send private messages (although currently via a workaround by typing
'/msg <user> <message>'.

Not sure I understand this. Private room messages are already supported by the GUI. Why are they not working out for you?

Once you receive a message, a new
(non-persistent) chat room emerges.)

Hmm ... this doesn't sound right. Our current implementation handles private in-room chats as regular chats with volatile contacts. Is there a reason why this would need to be different with IRC?

- Correctly handle nick changes, users joining, leaving, being kicked,
quitting. ==> Hence the list of chat room members should be current at
all times.
- Listing available chat rooms on a server. (Queries the list once, then
stores the result.)

Lists it when? Upon sending a /list command? Also isn't this caching a bit risky? How do you know when to update the list?

- A few channel mode changes are recognized, currently: member status
changes (default, voiced, opped, owner) for both yourself and fellow
chat room members.

All of this sounds like a really nice start!

Now what's still to be done: (A lot ...)
- Correct detection of channel forwarding
- Correct detection of some join failures
- Other channel mode changes.
- Private messaging via UI (double clicking chat room member)
- IRC formatting (which also fixes an issue that corrupts a specific
channel's history file when control characters are sent and stored.)
- DCC support
- Lots of stuff ...

Would you like to create those as issues? I'd be happy to open up an IRC component for you if you wish.

Note that because of some (mostly minor) issues I encountered in the IRC
library, some change is going on there too. So this library, too, is in
motion.

All in all, I would like to work towards a stable though somewhat
minimal working IRC implementation and improve from there.

+1

And for that
I would like to ask for help from some other adventurous souls who are
willing to spend some time using and testing the implementation and who
will report any bugs, stack traces, etc. they encounter.

Anyone willing to help?

I'd be more than happy to try it out!

Anyone with suggestions on how we can best approach this? I.e.
  - merge into nightly?

Yes, sounds reasonable. We could add an "(Experimental)" label behind the protocol display name at first and, if necessary, deactivate it before the next stable.

Incidentally, do you have a lot of changes outside protocol.impl.irc?

  - keep separate repo that is up to date with nightly?
  - create separate bundles to add? (can those be added easily to an
existing installation?)

I think the first option would give us most traction among users.

I'm curious to all of your thoughts and responses!

Thanks again for your efforts!

Emil

···

On 12.01.14, 14:52, Danny van Heumen wrote:

--
https://jitsi.org


#3

Hey

I think that the IRC implementation is (almost) at a stage now,

Youhouuu! :slight_smile:
Very nice! Looking forward to the pull request.

Thanks for your work Danny!

I don't know any details of IRC, so I'm just went through your commits and
have some comments. I hope I don't sound too nitpicking, I really look
forward to get this into trunk.

- Can you rebase please against the current head (AFAIK you do this anyway
regularly)
- Please remove the CLASSPATH_ATTR_LIBRARY_PATH_ENTRY property from
.classpath, this can be set as an environment variable in a
run-configuration (so that it doesn't affect all users)
- You said the ircapi is an active project. Any chance you could get them to
include the OSGi-metadata into the jar? And then just copy the jar over in
the build.xml instead of rebundling it? I see ircapi uses Maven, so this
should be "a piece of cake" (if they collaborate).*
- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*
- The changes in ChatRoomTableDialog.java look weird. Are you sure the
commented code there is not necessary? If so, completely remove it (the
reformats seem unnecessary too).
- Mode.java: Lacks the default license header. (And you might want to use
your full name instead of "danny" as author? Up to you)
- ModeParser.java: Lacks license header, class Javadoc
- FirstWizardPage.java: Line length
- IrcAccRegWizzActivator.java: Line length

Overall, good work!

[...]

Emil

Ingo

* Rationale: This helps with the Debian builds. We can simply add a
reference for those projects that already have a Debian package.


#4

Hi Emil,

Hey Danny,

Hi,

I think that the IRC implementation is (almost) at a stage now,

Youhouuu! :slight_smile:
Very nice! Looking forward to the pull request.

I like your enthusiasm.

where it
would be nice to have a larger audience look at it and use it. It is
still rather far from a complete implementation, especially if you
consider all the additional channel modes and such that have been
introduced by individual servers.

What is currently possible is the following:
- Create (and edit) IRC accounts. (Inherited from the old
implementation, just added a few tweaks.)
- Support for secure connections (minimal UI tweaks in order to indicate
a secure connection)
- Join chatrooms
- Send and receive messages
- Receive private messages.
- Send private messages (although currently via a workaround by typing
'/msg <user> <message>'.

Not sure I understand this. Private room messages are already
supported by the GUI. Why are they not working out for you?

When I use the UI capabilities it looks for a MetaContact instance which
is not available. I don't have a reference at hand right now, but my
earlier question about Persistent Presence was about that, because I
though it was necessary in order to get a MetaContact instance.

From what I understood from Hristo, there is a shorter way. So I am

going to try that next. I was trying to stabilize stuff, so I didn't
have time to try this immediately. So, basically the UI isn't lacking in
any way, it is just that I couldn't find the right way to set up
everything correctly.

Once you receive a message, a new
(non-persistent) chat room emerges.)

Hmm ... this doesn't sound right. Our current implementation handles
private in-room chats as regular chats with volatile contacts. Is
there a reason why this would need to be different with IRC?

Same reason as described above.

- Correctly handle nick changes, users joining, leaving, being kicked,
quitting. ==> Hence the list of chat room members should be current at
all times.
- Listing available chat rooms on a server. (Queries the list once, then
stores the result.)

Lists it when? Upon sending a /list command? Also isn't this caching a
bit risky? How do you know when to update the list?

When you go to the 'Add chat room' menu item and select the appropriate
account (IRC Account). Then click 'List' to get a listing of all
available channels.
Caveat there is (if I remember correctly) that upon typing parts of a
channel name in order to search, it continuously rerequests the server
chat room list. For IRC servers this is a very large list and also they
do not like it if you keep requesting before the previous listing was
completed. Therefore I decided that in this first version I would
request once, then cache the list. So, yes, new channels that were
created after the cache was created are not available. That does not
keep you from typing them in manually, though.
We might need to let this cache expire in, say, a few minutes or so.
That would probably work fairly nicely. Anyways, these kinds of things
is exactly why I like to get feedback from others.

- A few channel mode changes are recognized, currently: member status
changes (default, voiced, opped, owner) for both yourself and fellow
chat room members.

All of this sounds like a really nice start!

I agree :wink:

Now what's still to be done: (A lot ...)
- Correct detection of channel forwarding
- Correct detection of some join failures
- Other channel mode changes.
- Private messaging via UI (double clicking chat room member)
- IRC formatting (which also fixes an issue that corrupts a specific
channel's history file when control characters are sent and stored.)
- DCC support
- Lots of stuff ...

Would you like to create those as issues? I'd be happy to open up an
IRC component for you if you wish.

Well, there would be a lot of them though. I've got a lot of TODOs
throughout the code, which list the issues. An 'IRC' component is useful
though. In the very least to gather the user's findings.

Note that because of some (mostly minor) issues I encountered in the IRC
library, some change is going on there too. So this library, too, is in
motion.

All in all, I would like to work towards a stable though somewhat
minimal working IRC implementation and improve from there.

+1

And for that
I would like to ask for help from some other adventurous souls who are
willing to spend some time using and testing the implementation and who
will report any bugs, stack traces, etc. they encounter.

Anyone willing to help?

I'd be more than happy to try it out!

Anyone with suggestions on how we can best approach this? I.e.
  - merge into nightly?

Yes, sounds reasonable. We could add an "(Experimental)" label behind
the protocol display name at first and, if necessary, deactivate it
before the next stable.

Incidentally, do you have a lot of changes outside protocol.impl.irc?

I think the GUI code was separated. Obviously that code has some changes.
Other than that it was fairly minimal. I do have some old change
remnants from before MUC interface was changed. That might be in the
way. It might be a good thing for a second pair of eyes to review
non-IRC changes.

  - keep separate repo that is up to date with nightly?
  - create separate bundles to add? (can those be added easily to an
existing installation?)

I think the first option would give us most traction among users.

Okay, if that option isn't too much trouble, I am obviously fine with
that :slight_smile:

I'm curious to all of your thoughts and responses!

Thanks again for your efforts!

Emil

I'll send a pull request in a few days. Up to now I haven't exactly
followed all the coding rules to the letter, so there really is
improvement possible in all areas.

Danny

···

On 01/12/2014 04:23 PM, Emil Ivov wrote:

On 12.01.14, 14:52, Danny van Heumen wrote:


#5

Hi Ingo,

I don't mind nitpicking. These are valid points. I'll have a look at them.

Hey

I think that the IRC implementation is (almost) at a stage now,

Youhouuu! :slight_smile:
Very nice! Looking forward to the pull request.

Thanks for your work Danny!

I don't know any details of IRC, so I'm just went through your commits and
have some comments. I hope I don't sound too nitpicking, I really look
forward to get this into trunk.

- Can you rebase please against the current head (AFAIK you do this anyway
regularly)

I do, just haven't had time to do it recently.

- Please remove the CLASSPATH_ATTR_LIBRARY_PATH_ENTRY property from
.classpath, this can be set as an environment variable in a
run-configuration (so that it doesn't affect all users)

Right, I used that before I found the correct environment variable.
BTW, could you add that to the developer documentation? I recently sent
in a mail about that. (The environment variable in Linux is called
LD_LIBRARY_PATH if I remember correctly.)

- You said the ircapi is an active project. Any chance you could get them to
include the OSGi-metadata into the jar? And then just copy the jar over in
the build.xml instead of rebundling it? I see ircapi uses Maven, so this
should be "a piece of cake" (if they collaborate).*

I guess that could be done. I don't know much about OSGI though - Jitsi
is the first time I encounter it in practice.

- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*

Okay, thanks, I will undoubtedly have other things to learn about OSGI.
(Found out about the manifest files the hard way already :-P)

- The changes in ChatRoomTableDialog.java look weird. Are you sure the
commented code there is not necessary? If so, completely remove it (the
reformats seem unnecessary too).

I think these changes crossed Hristo's MUC redesign. There was some
duplicate code there where I simply called another chat window open
operation, so if I remember correctly that was the reason why a lot of
code was commented out.

- Mode.java: Lacks the default license header. (And you might want to use
your full name instead of "danny" as author? Up to you)
- ModeParser.java: Lacks license header, class Javadoc
- FirstWizardPage.java: Line length
- IrcAccRegWizzActivator.java: Line length

Thanks, I'll fix those.

Danny

···

On 01/12/2014 04:56 PM, Ingo Bauersachs wrote:

Overall, good work!

[...]

Emil

Ingo

* Rationale: This helps with the Debian builds. We can simply add a
reference for those projects that already have a Debian package.

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

--
Danny


#6

Hey Danny

Not sure I understand this. Private room messages are already
supported by the GUI. Why are they not working out for you?

When I use the UI capabilities it looks for a MetaContact instance which
is not available. I don't have a reference at hand right now, but my
earlier question about Persistent Presence was about that, because I
though it was necessary in order to get a MetaContact instance.

From what I understood from Hristo, there is a shorter way. So I am

going to try that next. I was trying to stabilize stuff, so I didn't
have time to try this immediately. So, basically the UI isn't lacking in
any way, it is just that I couldn't find the right way to set up
everything correctly.

OK great. Yes, volatile/non-persistent contacts should solve the issue for you. You would indeed need to provider an implementation of the presence operation set but it would be a *very* straightforward one.

Lists it when? Upon sending a /list command? Also isn't this caching a
bit risky? How do you know when to update the list?

When you go to the 'Add chat room' menu item and select the appropriate
account (IRC Account). Then click 'List' to get a listing of all
available channels.
Caveat there is (if I remember correctly) that upon typing parts of a
channel name in order to search, it continuously rerequests the server
chat room list.

That actually depends on on the "contact source" that implements this. The GUI would indeed execute a new search with the "contact source" every time you type.

For IRC servers this is a very large list and also they
do not like it if you keep requesting before the previous listing was
completed.

The GUI does "cancel" to previous searches before it executes new ones. I realise that this might not be implementable over IRC of course, but I thought I'd mention it.

Therefore I decided that in this first version I would
request once, then cache the list. So, yes, new channels that were
created after the cache was created are not available. That does not
keep you from typing them in manually, though.
We might need to let this cache expire in, say, a few minutes or so.
That would probably work fairly nicely.

Agreed. I'd even go down to one minute. This way, typing wouldn't cause multiple searches but the list would still be relatively fresh most of the time.

Also, how do you store it right now? Is it in-memory, or do you right it on the disk?

- DCC support

Forgot to comment on that one, but would we really ever want it? I know it used to be super popular in the late 1990s but does it still matter? XMPP and SIP have gone much further in that regard especially as far as NAT traversal is concerned.

Would you like to create those as issues? I'd be happy to open up an
IRC component for you if you wish.

Well, there would be a lot of them though.

That's not a problem for us and you can feel free to decide what granularity works best for you.

I've got a lot of TODOs
throughout the code, which list the issues. An 'IRC' component is useful
though. In the very least to gather the user's findings.

Done.

Incidentally, do you have a lot of changes outside protocol.impl.irc?

I think the GUI code was separated. Obviously that code has some changes.

It would be very helpful if you could summarize them here when you get the chance. The goal would be to use the same code for both XMPP and IRC rooms so there shouldn't be any protocol-specific code in the GUI.

This would be very important when we start transitioning to the new HTML5 GUI.

Other than that it was fairly minimal. I do have some old change
remnants from before MUC interface was changed. That might be in the
way. It might be a good thing for a second pair of eyes to review
non-IRC changes.

Yup. That's what I had in mind above.

I'll send a pull request in a few days. Up to now I haven't exactly
followed all the coding rules to the letter, so there really is
improvement possible in all areas.

OK looking forward to this.

Cheers,
Emil

···

On 12.01.14, 18:34, Danny van Heumen wrote:

--
https://jitsi.org


#7

Hi,

I am cleaning up a bit and processing the feedback that was given. Below
is the response on your feedback.

...

- Can you rebase please against the current head (AFAIK you do this anyway
regularly)

Done.

- Please remove the CLASSPATH_ATTR_LIBRARY_PATH_ENTRY property from
.classpath, this can be set as an environment variable in a
run-configuration (so that it doesn't affect all users)

Done.

- You said the ircapi is an active project. Any chance you could get them to
include the OSGi-metadata into the jar? And then just copy the jar over in
the build.xml instead of rebundling it? I see ircapi uses Maven, so this
should be "a piece of cake" (if they collaborate).*

Added a TODO, will do, at a later time.

- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*

Done.

- The changes in ChatRoomTableDialog.java look weird. Are you sure the
commented code there is not necessary? If so, completely remove it (the
reformats seem unnecessary too).

The unnecessary formatting was by mistake I think. The reason for
changing the behavior was that the behavior deviated between
double-clicking a chatroom to join it, and selecting the chatroom then
joining by clicking the 'join' button. With the change it adopts the
behavior of the join-button. (I commented out the
duplicate-but-slightly-off implementation and called the open chat room
implementation of the join button ... or the other way around ...)
I am not sure whether or not this Dialog is even still used. With the
recent Chat UI changes, the ChatRoomTableDialog does not show anymore.
Or at least I have not found it yet.
Instead (I think) it has now been replaced by a more slimmed down 'Add
Chat Room' dialog. Did Hristo do the recent chat dialog changes? Maybe
he knows more about this.

I could remove this code if that is preferred. If so, does anyone know
what the easiest way is to edit out git history?

- Mode.java: Lacks the default license header. (And you might want to use
your full name instead of "danny" as author? Up to you)

Good point. Done.

- ModeParser.java: Lacks license header, class Javadoc

Done.

- FirstWizardPage.java: Line length

Done.

- IrcAccRegWizzActivator.java: Line length

Done.

Overall, good work!

Thanks, but let's test it first :wink:

Danny

···

On 01/12/2014 04:56 PM, Ingo Bauersachs wrote:


#8

Super excited about this. And also happy to hear core-team has no objections to testing this in the nightly channel. +1 for that decision, since that way it will be the easiest way to have many users test IRC once it’s at a level were we can say: let the dogs out and send a post to the users list showing how to enable IRC and mass test it.

Exciting times :slight_smile:

···

Am 12.01.2014 um 18:59 schrieb Danny van Heumen <danny@dannyvanheumen.nl>:

Hi Ingo,

I don't mind nitpicking. These are valid points. I'll have a look at them.

On 01/12/2014 04:56 PM, Ingo Bauersachs wrote:

Hey

I think that the IRC implementation is (almost) at a stage now,

Youhouuu! :slight_smile:
Very nice! Looking forward to the pull request.

Thanks for your work Danny!

I don't know any details of IRC, so I'm just went through your commits and
have some comments. I hope I don't sound too nitpicking, I really look
forward to get this into trunk.

- Can you rebase please against the current head (AFAIK you do this anyway
regularly)

I do, just haven't had time to do it recently.

- Please remove the CLASSPATH_ATTR_LIBRARY_PATH_ENTRY property from
.classpath, this can be set as an environment variable in a
run-configuration (so that it doesn't affect all users)

Right, I used that before I found the correct environment variable.
BTW, could you add that to the developer documentation? I recently sent
in a mail about that. (The environment variable in Linux is called
LD_LIBRARY_PATH if I remember correctly.)

- You said the ircapi is an active project. Any chance you could get them to
include the OSGi-metadata into the jar? And then just copy the jar over in
the build.xml instead of rebundling it? I see ircapi uses Maven, so this
should be "a piece of cake" (if they collaborate).*

I guess that could be done. I don't know much about OSGI though - Jitsi
is the first time I encounter it in practice.

- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*

Okay, thanks, I will undoubtedly have other things to learn about OSGI.
(Found out about the manifest files the hard way already :-P)

- The changes in ChatRoomTableDialog.java look weird. Are you sure the
commented code there is not necessary? If so, completely remove it (the
reformats seem unnecessary too).

I think these changes crossed Hristo's MUC redesign. There was some
duplicate code there where I simply called another chat window open
operation, so if I remember correctly that was the reason why a lot of
code was commented out.

- Mode.java: Lacks the default license header. (And you might want to use
your full name instead of "danny" as author? Up to you)
- ModeParser.java: Lacks license header, class Javadoc
- FirstWizardPage.java: Line length
- IrcAccRegWizzActivator.java: Line length

Thanks, I'll fix those.

Danny

Overall, good work!

[...]

Emil

Ingo

* Rationale: This helps with the Debian builds. We can simply add a
reference for those projects that already have a Debian package.

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

--
Danny

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


#9

Hey,

...
The GUI does "cancel" to previous searches before it executes new
ones. I realise that this might not be implementable over IRC of
course, but I thought I'd mention it.

Okay, I'll have a look at that some time.

Therefore I decided that in this first version I would
request once, then cache the list. So, yes, new channels that were
created after the cache was created are not available. That does not
keep you from typing them in manually, though.
We might need to let this cache expire in, say, a few minutes or so.
That would probably work fairly nicely.

Agreed. I'd even go down to one minute. This way, typing wouldn't
cause multiple searches but the list would still be relatively fresh
most of the time.

Also, how do you store it right now? Is it in-memory, or do you right
it on the disk?

It's just your done-in-a-minute in-memory implementation. Basically the
return type, which is a List<String> IIRC.

- DCC support

Forgot to comment on that one, but would we really ever want it? I
know it used to be super popular in the late 1990s but does it still
matter? XMPP and SIP have gone much further in that regard especially
as far as NAT traversal is concerned.

Honestly, I would be really interested to see if anyone cares about this
... The only useful case that I can think of is file transfers. I am not
sure if there is another way - without DCC - to make that work.

...
It would be very helpful if you could summarize them here when you get
the chance. The goal would be to use the same code for both XMPP and
IRC rooms so there shouldn't be any protocol-specific code in the GUI.

This would be very important when we start transitioning to the new
HTML5 GUI.

I'll check. I don't think there is many.

...

Regards,
Danny

···

On 01/12/2014 07:51 PM, Emil Ivov wrote:


#10

[...]

The changes in
ChatRoomTableDialog.java look weird. Are you sure the commented code
there is not necessary? If so, completely remove it (the reformats seem
unnecessary too).

The unnecessary formatting was by mistake I think. The reason for
changing the behavior was that the behavior deviated between
double-clicking a chatroom to join it, and selecting the chatroom then
joining by clicking the 'join' button. With the change it adopts the
behavior of the join-button. (I commented out the
duplicate-but-slightly-off implementation and called the open chat room
implementation of the join button ... or the other way around ...)
I am not sure whether or not this Dialog is even still used. With the
recent Chat UI changes, the ChatRoomTableDialog does not show anymore.
Or at least I have not found it yet.
Instead (I think) it has now been replaced by a more slimmed down 'Add
Chat Room' dialog. Did Hristo do the recent chat dialog changes? Maybe
he knows more about this.

I have absolutely no idea what that code actually does/did. Someone else who
knows more would have to answer this.

I could remove this code if that is preferred. If so, does anyone know
what the easiest way is to edit out git history?

git rebase master --interactive

[...]
Danny

Ingo


#11

A quick question: why is slf4j needed? Is that about the IRC lib?

Emil

···

On Sun, Jan 12, 2014 at 6:59 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*


#12

- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*

A quick question: why is slf4j needed? Is that about the IRC lib?

Yep.

···

On 01/17/2014 10:47 PM, Emil Ivov wrote:

On Sun, Jan 12, 2014 at 6:59 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:
Emil

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


#13

About the ChatRoomTableDialog ...
It is a separate chat room management window where you can see the chat
rooms, which ones are joined and others. You can add, join, leave,
remove chat rooms. This has now all been incorporated in the contact
list though, so not immediately relevant. The only exception I can think
of, is when some menu item still shows this window for some reason.

···

On 01/17/2014 10:42 PM, Ingo Bauersachs wrote:

[...]

The changes in
ChatRoomTableDialog.java look weird. Are you sure the commented code
there is not necessary? If so, completely remove it (the reformats seem
unnecessary too).

The unnecessary formatting was by mistake I think. The reason for
changing the behavior was that the behavior deviated between
double-clicking a chatroom to join it, and selecting the chatroom then
joining by clicking the 'join' button. With the change it adopts the
behavior of the join-button. (I commented out the
duplicate-but-slightly-off implementation and called the open chat room
implementation of the join button ... or the other way around ...)
I am not sure whether or not this Dialog is even still used. With the
recent Chat UI changes, the ChatRoomTableDialog does not show anymore.
Or at least I have not found it yet.
Instead (I think) it has now been replaced by a more slimmed down 'Add
Chat Room' dialog. Did Hristo do the recent chat dialog changes? Maybe
he knows more about this.

I have absolutely no idea what that code actually does/did. Someone else who
knows more would have to answer this.

I could remove this code if that is preferred. If so, does anyone know
what the easiest way is to edit out git history?

git rebase master --interactive

[...]
Danny

Ingo

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

--
Danny


#14

It might be possible to use some other already available logging
library, maybe. My focus has been on the implementation of IRC support,
so I didn't look to closely for that.

···

On 01/17/2014 10:47 PM, Emil Ivov wrote:

On Sun, Jan 12, 2014 at 6:59 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

- SLF4J is already OSGi-aware, so please just copy the jars over (e.g. like
log4j, guava, commons-codec, etc.)*

A quick question: why is slf4j needed? Is that about the IRC lib?


#15

Hello Danny,

The current version of ChatRoomTableDialog is the "Add chat room" dialog which is displayed from File -> Add chat room. Before the implementation of the chat room contacts in the contact list the ChatRoomTableDialog was the only place where you can manage your chat rooms. Since we add the most of functionality implemented in the ChatRoomTableDialog in the contact list we removed the list of chatrooms and the add / remove buttons from the dialog. At the moment the ChatRoomTableDialog is used only for adding new chat rooms to the contact list.

Maybe we should rename the class.

Regards,
Hristo.

···

On Jan 18, 2014, at 12:46 AM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

About the ChatRoomTableDialog ...
It is a separate chat room management window where you can see the chat
rooms, which ones are joined and others. You can add, join, leave,
remove chat rooms. This has now all been incorporated in the contact
list though, so not immediately relevant. The only exception I can think
of, is when some menu item still shows this window for some reason.

On 01/17/2014 10:42 PM, Ingo Bauersachs wrote:

[...]

The changes in
ChatRoomTableDialog.java look weird. Are you sure the commented code
there is not necessary? If so, completely remove it (the reformats seem
unnecessary too).

The unnecessary formatting was by mistake I think. The reason for
changing the behavior was that the behavior deviated between
double-clicking a chatroom to join it, and selecting the chatroom then
joining by clicking the 'join' button. With the change it adopts the
behavior of the join-button. (I commented out the
duplicate-but-slightly-off implementation and called the open chat room
implementation of the join button ... or the other way around ...)
I am not sure whether or not this Dialog is even still used. With the
recent Chat UI changes, the ChatRoomTableDialog does not show anymore.
Or at least I have not found it yet.
Instead (I think) it has now been replaced by a more slimmed down 'Add
Chat Room' dialog. Did Hristo do the recent chat dialog changes? Maybe
he knows more about this.

I have absolutely no idea what that code actually does/did. Someone else who
knows more would have to answer this.

I could remove this code if that is preferred. If so, does anyone know
what the easiest way is to edit out git history?

git rebase master --interactive

[...]
Danny

Ingo

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

--
Danny

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