Hey
Are there major open issues that would prevent us from releasing a new
stable version?
Ingo
Yes:
Please fixing the issues with OTR and OTR-padlock (George Politis is
aware of that) and the connected problems
kind regards,
MS
···
On 11/10/14 1:15 PM, Ingo Bauersachs wrote:
Hey
Are there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
IRC seems to be pretty stable right now.
There are no major bugs AFAIK.
So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
···
On 10-11-14 08:45, Ingo Bauersachs wrote:
Hey
Are there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
Hey all,
I want to call some attention to this thread again. I've read quite a
bit about plans on improving Jitsi in various ways. Things that I've
read about:
* Mavenization
* Upgrade Java source support to 1.7/1.8 and use all shiny new language
features
* Clean up some parts of the code, compiler warnings etc.
Personally I've been looking at:
* introducing more advanced use of Generics for Jitsi's interfaces such
as the Contact, ContactGroup, ProtocolProviderService, etc. such that we
can do away with quite a bit of type casting, within a single
Protocol-implementation for example.
* Introduction of notion of presence for chat room members.
etc.
So, do we have any plans to conclude short term modifications and
release a new stable version?
For me, I'd like to fix a few things, which I will do in the upcoming days:
1. Fix UI bug which asks twice if user wants to close a chat room window
when click 'leave' just after a new message has arrived.
2. Fix copy-paste issues in ChatConversionPanel.
3. Also catch and handle IllegalStateException for IRC command
execution. (trivial)
4. Simplify OTR fragmentation implementation (done but not merged yet)
(Mainly to correct a design decision I regret. No impact in functionality.)
I've been saving up other improvements for after the coming release.
Danny
···
On 10-11-14 08:45, Ingo Bauersachs wrote:
Hey
Are there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
I don't think we have any regressions on our side as per the previous
stable version (while OTR deserves a fix I don't think it is a blocker
for the new stable).
There is however one serious regression on OS X, where the current
version is having some visible problems running on Yosemite. I
wouldn't call this exactly a release blocker either but ... it would
be nice if someone could have a look ... we might be able to do this
within a month or so.
Anyone else?
Emil
···
On Mon, Nov 10, 2014 at 10:51 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:
IRC seems to be pretty stable right now.
There are no major bugs AFAIK.So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
On 10-11-14 08:45, Ingo Bauersachs wrote:
Hey
Are there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
I want to call some attention to this thread again. I've read quite a
bit about plans on improving Jitsi in various ways. Things that I've
read about:
* Mavenization
That'll be a long term goal, if at all. The start should definitely be
libjitsi before we even try to attack Jitsi itself.
* Upgrade Java source support to 1.7/1.8 and use all shiny new language
features* Clean up some parts of the code, compiler warnings etc.
IMO that should be done once and for all to avoid cluttering the history
with "Formatting" commits, and, worse, inline with actual functional
changes.
Personally I've been looking at:
* introducing more advanced use of Generics for Jitsi's interfaces such
as the Contact, ContactGroup, ProtocolProviderService, etc. such that we
can do away with quite a bit of type casting, within a single
Protocol-implementation for example.
Hm, I wonder how much it is worth to invest time in that code. I wanted to
take look at replacing the UI with JavaFX or investigate the CEF work a
little further. If that would be done, a lot of the code for the contactlist
would be destroy&recreate, particularly to finally handle having one contact
in multiple groups.
* Introduction of notion of presence for chat room members.
etc.So, do we have any plans to conclude short term modifications and
release a new stable version?
I think with the two commits I made today for the Mac-Launcher, we should be
ready to finally call the translators to finish their work.
For me, I'd like to fix a few things, which I will do in the upcoming
days:
1. Fix UI bug which asks twice if user wants to close a chat room window
when click 'leave' just after a new message has arrived.
2. Fix copy-paste issues in ChatConversionPanel.
3. Also catch and handle IllegalStateException for IRC command
execution. (trivial)
Go for them.
4. Simplify OTR fragmentation implementation (done but not merged yet)
(Mainly to correct a design decision I regret. No impact in
functionality.)
If you think the current state is stable enough, then this might be
something to wait.
I've been saving up other improvements for after the coming release.
I'm not having anything particular ready, but there's definitely still a
whole lot of work to do...
Danny
Ingo
I don't think we have any regressions on our side as per the previous
stable version (while OTR deserves a fix I don't think it is a blocker
for the new stable).
I can't really remember what the issue is here and neither does Danny. Can someone please describe that in more detail or post a link to the archives?
There is however one serious regression on OS X, where the current
version is having some visible problems running on Yosemite. I
wouldn't call this exactly a release blocker either but ... it would
be nice if someone could have a look ... we might be able to do this
within a month or so.
I was running Jitsi on Yosemite while trying to debug the Java7+ video issue and saw nothing wrong (when running on Java6 obviously). Could you please be a bit more specific so that I can take a look?
Anyone else?
Emil
Ingo
···
On 11.11.2014, at 00:31, Emil Ivov <emcho@jitsi.org> wrote:
On Mon, Nov 10, 2014 at 10:51 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:
IRC seems to be pretty stable right now.
There are no major bugs AFAIK.So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
On 10-11-14 08:45, Ingo Bauersachs wrote:
HeyAre there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
minor:
if someone wants with Jitsi to chat via TOR (SOCKS5, 127.0.0.1, port
9050) it does not work...
we had longer time discussions about usefulness to chat via TOR in the
jitsi forum,
but at that time also the conclusion was the the proxy settings in Jitsi
needed attention/checking/refurbishment
br, thx!
MS
···
On 11/11/14 4:59 AM, Emil Ivov wrote:
I don't think we have any regressions on our side as per the previous
stable version (while OTR deserves a fix I don't think it is a blocker
for the new stable).There is however one serious regression on OS X, where the current
version is having some visible problems running on Yosemite. I
wouldn't call this exactly a release blocker either but ... it would
be nice if someone could have a look ... we might be able to do this
within a month or so.Anyone else?
Emil
On Mon, Nov 10, 2014 at 10:51 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:
IRC seems to be pretty stable right now.
There are no major bugs AFAIK.So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
On 10-11-14 08:45, Ingo Bauersachs wrote:
Hey
Are there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
I don't think we have any regressions on our side as per the previous
stable version (while OTR deserves a fix I don't think it is a blocker
for the new stable).There is however one serious regression on OS X, where the current
version is having some visible problems running on Yosemite. I
wouldn't call this exactly a release blocker either but ... it would
be nice if someone could have a look ... we might be able to do this
within a month or so.
Does that happen with 2.4.4997 as well? If not, can we call for a string
freeze and translation to make a release next weekend?
Anyone else?
Emil
Ingo
I want to call some attention to this thread again. I've read quite a
bit about plans on improving Jitsi in various ways. Things that I've
read about:
* MavenizationThat'll be a long term goal, if at all. The start should definitely be
libjitsi before we even try to attack Jitsi itself.
Do you expect this to be so problematic?
On the other hand, it might be good to look at Gradle first. It may even
be easier and better to use Gradle instead of Maven. IIRC Gradle has
dependency management compatible with Maven's, but uses a declarative
syntax for its configuration. That might be more similar to our current
ant build script. (I'm not sure about this, though. I haven't used
Gradle yet. Only heard/read some about it.)
* Upgrade Java source support to 1.7/1.8 and use all shiny new language
features* Clean up some parts of the code, compiler warnings etc.
IMO that should be done once and for all to avoid cluttering the history
with "Formatting" commits, and, worse, inline with actual functional
changes.
Maybe use a formatting plugin upon (before) building. No discussion, all
formatting is done by the same system. Instead of it being determined by
the IDE in use.
Personally I've been looking at:
* introducing more advanced use of Generics for Jitsi's interfaces such
as the Contact, ContactGroup, ProtocolProviderService, etc. such that we
can do away with quite a bit of type casting, within a single
Protocol-implementation for example.Hm, I wonder how much it is worth to invest time in that code. I wanted to
take look at replacing the UI with JavaFX or investigate the CEF work a
little further. If that would be done, a lot of the code for the contactlist
would be destroy&recreate, particularly to finally handle having one contact
in multiple groups.
That's also a possibility. I got the impression that handling MUC
artifacts, such as chat rooms, as contacts is something recent. Maybe
since the changes Hristo made? I noticed occasional more limited options
compared to IM contacts. We would also be able to handle IM and MUC
contacts equally from the start. (I like that approach at least.)
* Introduction of notion of presence for chat room members.
etc.So, do we have any plans to conclude short term modifications and
release a new stable version?I think with the two commits I made today for the Mac-Launcher, we should be
ready to finally call the translators to finish their work.
Great.
For me, I'd like to fix a few things, which I will do in the upcoming
days:
1. Fix UI bug which asks twice if user wants to close a chat room window
when click 'leave' just after a new message has arrived.
2. Fix copy-paste issues in ChatConversionPanel.
3. Also catch and handle IllegalStateException for IRC command
execution. (trivial)Go for them.
Yep am doing that already.
4. Simplify OTR fragmentation implementation (done but not merged yet)
(Mainly to correct a design decision I regret. No impact infunctionality.)
If you think the current state is stable enough, then this might be
something to wait.
The disadvantage here is that would mean changing the interface again.
And this is something that isn't in use yet. But yeah, you're probably
right.
I've been saving up other improvements for after the coming release.
I'm not having anything particular ready, but there's definitely still a
whole lot of work to do...
For IRC that's easier. I still need to catch up with other protocols 
Danny
···
On 06-12-14 16:50, Ingo Bauersachs wrote:
Danny
Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
Hello,
I don't think we have any regressions on our side as per the previous
stable version (while OTR deserves a fix I don't think it is a blocker
for the new stable).I can't really remember what the issue is here and neither does Danny. Can someone please describe that in more detail or post a link to the archives?
The Jitsi OTR plugin tries to keep track of the otr4j engine internal
state outside of otr4j. I believe that, at some point, we introduced the
state tracking mechanism so that we can time out a session.
ScOtrEngineImpl has an ScSessionStatusScheduler that times out sessions,
and we have an ScSessionStatus enumeration that has one extra item
defined, called TIMED_OUT (the otr4j internal session status enumeration
doesn't have that).
The problem is that sometimes the Jitsi OTR plugin loses track of the
otr4j engine internal state. Therefore, the padlock icon does not
reflect the real OTR state. It's a downhill from there because the
plugin takes actions based on its own state rather than the real OTR state.
My plan was to remove the additional state tracking from the OTR plugin
and instead rely entirely on otr4j but that hasn't happened yet.
Cheers,
George
···
On 11/11/2014 06:47, Ingo Bauersachs wrote:
On 11.11.2014, at 00:31, Emil Ivov <emcho@jitsi.org> wrote:
There is however one serious regression on OS X, where the current
version is having some visible problems running on Yosemite. I
wouldn't call this exactly a release blocker either but ... it would
be nice if someone could have a look ... we might be able to do this
within a month or so.I was running Jitsi on Yosemite while trying to debug the Java7+ video issue and saw nothing wrong (when running on Java6 obviously). Could you please be a bit more specific so that I can take a look?
Anyone else?
Emil
Ingo
On Mon, Nov 10, 2014 at 10:51 PM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:
IRC seems to be pretty stable right now.
There are no major bugs AFAIK.So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
On 10-11-14 08:45, Ingo Bauersachs wrote:
HeyAre there major open issues that would prevent us from releasing a new
stable version?Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
I was running Jitsi on Yosemite while trying to debug the Java7+
video issue and saw nothing wrong (when running on Java6 obviously).
Could you please be a bit more specific so that I can take a look?
It flickers. It happens at what appear to be arbitrary times. To me it happened when Jitsi was positioned on top of other applications.
This is likely a Java/OS X problem but maybe it would disappear once we upgrade to J7.
Emil
···
On 11.11.14, 6:47, Ingo Bauersachs wrote:
Anyone else?
Emil
Ingo
On Mon, Nov 10, 2014 at 10:51 PM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:
IRC seems to be pretty stable right now. There are no major bugs
AFAIK.So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
On 10-11-14 08:45, Ingo Bauersachs wrote: Hey
Are there major open issues that would prevent us from
releasing a new stable version?Ingo
_______________________________________________ dev mailing
list dev@jitsi.org Unsubscribe instructions and other list
options: http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
Let's first see what comes out of Lyubo's video investigation. I know he
started looking at this on Friday.
If he succeeds, we will be able to upgrade to J7 or J8 and that might also
fix the flickering issue.
Emil
--sent from my mobile
···
On 22 Nov 2014 1:05 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:
> I don't think we have any regressions on our side as per the previous
> stable version (while OTR deserves a fix I don't think it is a blocker
> for the new stable).
>
> There is however one serious regression on OS X, where the current
> version is having some visible problems running on Yosemite. I
> wouldn't call this exactly a release blocker either but ... it would
> be nice if someone could have a look ... we might be able to do this
> within a month or so.Does that happen with 2.4.4997 as well? If not, can we call for a string
freeze and translation to make a release next weekend?> Anyone else?
>
> EmilIngo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
I want to call some attention to this thread again. I've read quite a
bit about plans on improving Jitsi in various ways. Things that I've
read about:
* MavenizationThat'll be a long term goal, if at all. The start should definitely be
libjitsi before we even try to attack Jitsi itself.Do you expect this to be so problematic?
On the other hand, it might be good to look at Gradle first. It may even
be easier and better to use Gradle instead of Maven. IIRC Gradle has
dependency management compatible with Maven's, but uses a declarative
syntax for its configuration. That might be more similar to our current
ant build script. (I'm not sure about this, though. I haven't used
Gradle yet. Only heard/read some about it.)
I've never done anything with Gradle, and AFAIK it's a bit exotic, at least
more than Maven. Ivy would be another thing that uses the Maven repo. My
ultimate goal would be to have a bunch of projects/modules that compile
individually and the possibility to switch between Felix and Equinox so that
no recompile is necessary from within Eclipse. And I'm only specifically
mentioning Eclipse here because I know that it has specific OSGi
functionality built-in.
* Upgrade Java source support to 1.7/1.8 and use all shiny new language
features* Clean up some parts of the code, compiler warnings etc.
IMO that should be done once and for all to avoid cluttering the history
with "Formatting" commits, and, worse, inline with actual functional
changes.Maybe use a formatting plugin upon (before) building. No discussion, all
formatting is done by the same system. Instead of it being determined by
the IDE in use.
Yeah, some one-time format and then enforcement with Checkstyle at build
time, or if possible as a pre-commit hook that denies committing if it finds
violations. But that is an extremely low priority.
Personally I've been looking at:
* introducing more advanced use of Generics for Jitsi's interfaces such
as the Contact, ContactGroup, ProtocolProviderService, etc. such that we
can do away with quite a bit of type casting, within a single
Protocol-implementation for example.Hm, I wonder how much it is worth to invest time in that code. I wanted
to take look at replacing the UI with JavaFX or investigate the CEF
work a little further. If that would be done, a lot of the code for the
contactlist would be destroy&recreate, particularly to finally handle
having one contact in multiple groups.That's also a possibility. I got the impression that handling MUC
artifacts, such as chat rooms, as contacts is something recent. Maybe
since the changes Hristo made? I noticed occasional more limited options
compared to IM contacts. We would also be able to handle IM and MUC
contacts equally from the start. (I like that approach at least.)
I honestly have no idea about all the MUC stuff as I never use it.
* Introduction of notion of presence for chat room members.
etc.So, do we have any plans to conclude short term modifications and
release a new stable version?I think with the two commits I made today for the Mac-Launcher, we
should be ready to finally call the translators to finish their work.Great.
Something with MUC comes to mind: I played around with that a bit and saw
that all the chatroom options aren't localized. As you're familiar with
that: Do you have the time to i18n that dialog?
For me, I'd like to fix a few things, which I will do in the upcoming
days: 1. Fix UI bug which asks twice if user wants to close a chat
room window when click 'leave' just after a new message has arrived.
2. Fix copy-paste issues in ChatConversionPanel. 3. Also catch and
handle IllegalStateException for IRC command execution. (trivial)Go for them.
Yep am doing that already.
4. Simplify OTR fragmentation implementation (done but not merged yet)
(Mainly to correct a design decision I regret. No impact infunctionality.)
If you think the current state is stable enough, then this might be
something to wait.The disadvantage here is that would mean changing the interface again.
And this is something that isn't in use yet. But yeah, you're probably
right.
I don't know enough about that part. If you feel comfortable with whatever
you're doing, okay commit, otherwise wait. Your call.
I've been saving up other improvements for after the coming release.
I'm not having anything particular ready, but there's definitely still a
whole lot of work to do...For IRC that's easier. I still need to catch up with other protocols
Danny
Danny
Ingo
Ingo
···
On 06-12-14 16:50, Ingo Bauersachs wrote:
Hi all,
What does it take to upgrade to Java 7(+) on OS X?
There have been a few questions on the mailing list about this and as I
understand it, it has something to do with the launcher that we use(???)
Is that something we can modify? I am not able to test, since I do not
use OS X, but we can certainly find some people to do the testing.
And if that may also solve some other problems ... from the top of my head:
1. the problem with the video that you've described (maybe)
2. some issues with TLS (due to POODLE) or certificates (I'm not 100%
clear on the root cause), but I thought it was something related to
Facebook messaging connectivity that was caused by the (by now dated)
Java 6 JVM.
Wouldn't that be worth a look?
Again, I don't know this OS X launcher, so I might be underestimating
the effort it takes.
Danny
···
On 11-11-14 14:04, Emil Ivov wrote:
On 11.11.14, 6:47, Ingo Bauersachs wrote:
I was running Jitsi on Yosemite while trying to debug the Java7+
video issue and saw nothing wrong (when running on Java6 obviously).
Could you please be a bit more specific so that I can take a look?It flickers. It happens at what appear to be arbitrary times. To me it
happened when Jitsi was positioned on top of other applications.This is likely a Java/OS X problem but maybe it would disappear once
we upgrade to J7.Emil
Anyone else?
Emil
Ingo
On Mon, Nov 10, 2014 at 10:51 PM, Danny van Heumen >>> <danny@dannyvanheumen.nl> wrote:
IRC seems to be pretty stable right now. There are no major bugs
AFAIK.So ... no reason for my part not to release, I would say.
I'm not familiar with the OTR issue, though. Any references?
Danny
On 10-11-14 08:45, Ingo Bauersachs wrote: Hey
Are there major open issues that would prevent us from
releasing a new stable version?Ingo
_______________________________________________ dev mailing
list dev@jitsi.org Unsubscribe instructions and other list
options: http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
Hi,
Hello,
[...]
The Jitsi OTR plugin tries to keep track of the otr4j engine internal
state outside of otr4j. I believe that, at some point, we introduced the
state tracking mechanism so that we can time out a session.ScOtrEngineImpl has an ScSessionStatusScheduler that times out sessions,
and we have an ScSessionStatus enumeration that has one extra item
defined, called TIMED_OUT (the otr4j internal session status enumeration
doesn't have that).The problem is that sometimes the Jitsi OTR plugin loses track of the
otr4j engine internal state. Therefore, the padlock icon does not
reflect the real OTR state. It's a downhill from there because the
plugin takes actions based on its own state rather than the real OTR state.
Are you able to reproduce this reliably?
I have noticed something else when I was working on outgoing
fragmentation support. I noticed that Pidgin (OTR over IRC) didn't
correctly end the OTR session if I intentionally ended it from the
Pidgin side. This causes the clients to go out of sync, since one thinks
the session has ended while the other thinks it is active. But I haven't
noticed the issue you describe above.
My plan was to remove the additional state tracking from the OTR plugin
and instead rely entirely on otr4j but that hasn't happened yet.
That makes sense.
Kind regards,
Danny
···
On 11-11-14 10:09, George Politis wrote:
Let's first see what comes out of Lyubo's video investigation. I know he
started looking at this on Friday.
I committed fixes for whatever issues I knew about from your
conversation here and/or saw with JAWTRenderer on Java 8u25.
If he succeeds, we will be able to upgrade to J7 or J8 and that might also
fix the flickering issue.
I don't know what "the flickering issue" is.
···
2014-11-22 16:06 GMT+02:00 Emil Ivov <emcho@jitsi.org>:
On 22 Nov 2014 1:05 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:
If not, can we call for a string
freeze and translation to make a release next weekend?
As Damencho said, the launcher may need fixing. I tried looking into
it but I don't understand why it does half the things it does. (It's a
completely different approach from the crash handler/run executable
under Windows.)
[...]
Something with MUC comes to mind: I played around with that a bit and
saw that all the chatroom options aren't localized. As you're familiar
with that: Do you have the time to i18n that dialog?
I can have a look at it. I guess MUC is a bit behind on the i18n in
general, so I would expect things like error messages, menu items,
notifications and such to be a bit behind.
Danny
···
On 12/06/2014 06:47 PM, Ingo Bauersachs wrote:
For me, I'd like to fix a few things, which I will do in the upcoming
days: 1. Fix UI bug which asks twice if user wants to close a chat
room window when click 'leave' just after a new message has arrived.
2. Fix copy-paste issues in ChatConversionPanel. 3. Also catch and
handle IllegalStateException for IRC command execution. (trivial)Go for them.
Yep am doing that already.
4. Simplify OTR fragmentation implementation (done but not merged yet)
(Mainly to correct a design decision I regret. No impact infunctionality.)
If you think the current state is stable enough, then this might be
something to wait.The disadvantage here is that would mean changing the interface again.
And this is something that isn't in use yet. But yeah, you're probably
right.I don't know enough about that part. If you feel comfortable with whatever
you're doing, okay commit, otherwise wait. Your call.I've been saving up other improvements for after the coming release.
I'm not having anything particular ready, but there's definitely still a
whole lot of work to do...For IRC that's easier. I still need to catch up with other protocols
Danny
Danny
Ingo
Ingo
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
What does it take to upgrade to Java 7(+) on OS X?
Primarily: fixing the video rendering using JAWT.
There have been a few questions on the mailing list about this and as I
understand it, it has something to do with the launcher that we use(???)
Is that something we can modify? I am not able to test, since I do not
use OS X, but we can certainly find some people to do the testing.And if that may also solve some other problems ... from the top of my
head:
1. the problem with the video that you've described (maybe)
2. some issues with TLS (due to POODLE) or certificates (I'm not 100%
clear on the root cause), but I thought it was something related to
Facebook messaging connectivity that was caused by the (by now dated)
Java 6 JVM.Wouldn't that be worth a look?
As much as I hate OSX, I started looking at this because I want to move
forward with the JRE versions. However putting all my swearing about the
*cking OSX keyboard layout and window manager aside, that whole stuff is all
but trivial and I have no clue about what's going on deep down in
JAWT/CALayer/OpenGL and subclassing windows in ObjC. So it'll take a while.
And even if it works, it might be worth testing this a little while in the
nightlies.
Again, I don't know this OS X launcher, so I might be underestimating
the effort it takes.
It's not the launcher, AFAIK that is ready.
Danny
Ingo
Let's first see what comes out of Lyubo's video investigation. I know he
started looking at this on Friday.I committed fixes for whatever issues I knew about from your
conversation here and/or saw with JAWTRenderer on Java 8u25.
Thanks Lyubo!
However when I tried a 1:1 video call yesterday evening, the preview was
still hidden behind the remote video. Was that working for you?
If he succeeds, we will be able to upgrade to J7 or J8 and that might
also
fix the flickering issue.
I don't know what "the flickering issue" is.
If not, can we call for a string
freeze and translation to make a release next weekend?As Damencho said, the launcher may need fixing. I tried looking into
it but I don't understand why it does half the things it does. (It's a
completely different approach from the crash handler/run executable
under Windows.)
Ingo
···
2014-11-22 16:06 GMT+02:00 Emil Ivov <emcho@jitsi.org>:
On 22 Nov 2014 1:05 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote: