[jitsi-dev] Default software after file transfer


#1

Thanks for the quick answer.

Do you know if there is a reason, why Jitsi does not use the system defaults?
Or is it just so with Linux / KDE? - i haven't tried it with another OS yet.

Because except of this issue Jitsi is my favorite IM/VVoIP-App, since Kopete
is outdated and Telepathy is not really ready to use yet.

Greetings,
Florian.

Vom Dienstag, 10. Dezember 2013:

···

It is not currently possible to change this.

Emil

On 09.12.13, 19:29, Florian J. Lorenz wrote:
> Hello,
>
> i have a question regarding to Jitsis behaviour after a file transfer.
>
> After a file transfer is completed, you have the possibility of opening
> the file or the file-path out of Jitsi.
>
> Is there a possibility to change the default software?
>
> Firefox is my default Browser, but whenever i open a link from Jitsi, it
> opens Konqueror (my system opens Firefox out of every other application,
> like Okular, LibreOffice).
>
> Dolphin is my default File Manager, but whenever i open a file from Jitsi,
> it opens Gwenview.
>
> In case of pictures it opens GIMP instead of Gwenview, etc...
>
> I am running two laptops with openSUSE KDE 13.1.
>
> I hope, you could help me with this :slight_smile:
>
> Greetings,
> Florian.
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

-------------------------------------------------------------


#2

I think we currently use Java to figure this out since we don't need to worry about the different platforms.

If anyone would like to contribute an improvement there, that would definitely be welcome!

Emil

···

On 10.12.13, 20:02, Florian J. Lorenz wrote:

Thanks for the quick answer.

Do you know if there is a reason, why Jitsi does not use the system defaults?
Or is it just so with Linux / KDE? - i haven't tried it with another OS yet.

Because except of this issue Jitsi is my favorite IM/VVoIP-App, since Kopete
is outdated and Telepathy is not really ready to use yet.

Greetings,
Florian.

Vom Dienstag, 10. Dezember 2013:

It is not currently possible to change this.

Emil

On 09.12.13, 19:29, Florian J. Lorenz wrote:

Hello,

i have a question regarding to Jitsis behaviour after a file transfer.

After a file transfer is completed, you have the possibility of opening
the file or the file-path out of Jitsi.

Is there a possibility to change the default software?

Firefox is my default Browser, but whenever i open a link from Jitsi, it
opens Konqueror (my system opens Firefox out of every other application,
like Okular, LibreOffice).

Dolphin is my default File Manager, but whenever i open a file from Jitsi,
it opens Gwenview.

In case of pictures it opens GIMP instead of Gwenview, etc...

I am running two laptops with openSUSE KDE 13.1.

I hope, you could help me with this :slight_smile:

Greetings,
Florian.

_______________________________________________
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

--
https://jitsi.org


#3

Florian J. Lorenz wrote:

Thanks for the quick answer.

Do you know if there is a reason, why Jitsi does not use the system defaults?
Or is it just so with Linux / KDE? - i haven't tried it with another OS yet.

Because except of this issue Jitsi is my favorite IM/VVoIP-App, since Kopete
is outdated and Telepathy is not really ready to use yet.

Greetings,
Florian.

I have the same issue. On Linux there are more mechanisms that are used to assign the default program for a specified link or file type. There is a mimetype file list in text format, there are the predefined browsers in the alternatives mechanism.
I had the same issue with Chrome opening all the time instead of Seamonkey which i use as my main browser.
The solution was to set the gnome-www-browser, x-www-browser to point to my seamonkey binary. It seems that Jitsi uses these to determine the browser (or relies on some Java mechanism that uses these).

And thats not ok since not all DEs use these links. Also the default openers for other stuff like folders or files are interpreted differently too. I had to manually edit the mimetypes files.

···

Vom Dienstag, 10. Dezember 2013:

It is not currently possible to change this.

Emil

On 09.12.13, 19:29, Florian J. Lorenz wrote:

Hello,

i have a question regarding to Jitsis behaviour after a file transfer.

After a file transfer is completed, you have the possibility of opening
the file or the file-path out of Jitsi.

Is there a possibility to change the default software?

Firefox is my default Browser, but whenever i open a link from Jitsi, it
opens Konqueror (my system opens Firefox out of every other application,
like Okular, LibreOffice).

Dolphin is my default File Manager, but whenever i open a file from Jitsi,
it opens Gwenview.

In case of pictures it opens GIMP instead of Gwenview, etc...

I am running two laptops with openSUSE KDE 13.1.

I hope, you could help me with this :slight_smile:

Greetings,
Florian.

_______________________________________________
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

--
O zi buna,
Kertesz Laszlo


#4

Well a quick easy "win" for power-users might be a "browser command" .properties option that is user configurable, and just contains a shell command like 'firefox %s' (possibly with a better named escape value for the parameter but you see what I mean). Clicking a link would just invoke this program with the appropriate URL as an argument. Then in the UI we could present a dropdown list (with possible "Advanced/Other/Manual Entry") that allows the user to pick between the sensible browser choices that are found on his/her system. This UI option would just write the appropriate .properties option.

There would also be a "Default" setting that would keep behaviour as it is now.

I know this doesn't satisfy the "system default" constraint and this could be worked on separately to improve the "Default" option, but I think giving this control to the user (even without the UI through .properties/provisioning) would be useful.

I might be able to contribute some time towards getting the .properties backend working, although to be honest that's the most trivial part of my suggestion. I appreciate feedback on this.

Thanks,
Toby Pinder
Software Engineer | Smith Electric Vehicles

I think we currently use Java to figure this out since we don't need to
worry about the different platforms.

If anyone would like to contribute an improvement there, that would
definitely be welcome!

Emil

···

On 11/12/13 11:52, Emil Ivov wrote:

On 10.12.13, 20:02, Florian J. Lorenz wrote:

Thanks for the quick answer.

Do you know if there is a reason, why Jitsi does not use the system defaults?
Or is it just so with Linux / KDE? - i haven't tried it with another OS yet.

Because except of this issue Jitsi is my favorite IM/VVoIP-App, since Kopete
is outdated and Telepathy is not really ready to use yet.

Greetings,
Florian.

Vom Dienstag, 10. Dezember 2013:

It is not currently possible to change this.

Emil

On 09.12.13, 19:29, Florian J. Lorenz wrote:

Hello,

i have a question regarding to Jitsis behaviour after a file transfer.

After a file transfer is completed, you have the possibility of opening
the file or the file-path out of Jitsi.

Is there a possibility to change the default software?

Firefox is my default Browser, but whenever i open a link from Jitsi, it
opens Konqueror (my system opens Firefox out of every other application,
like Okular, LibreOffice).

Dolphin is my default File Manager, but whenever i open a file from Jitsi,
it opens Gwenview.

In case of pictures it opens GIMP instead of Gwenview, etc...

I am running two laptops with openSUSE KDE 13.1.

I hope, you could help me with this :slight_smile:

Greetings,
Florian.

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

-------------------------------------------------------------

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

--
https://jitsi.org

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


#5

Actually, the BrowserLauncherService tries a fixed list of browsers on
Linux. Mac uses a deprecated API (from JDIC?) and Windows a shell-call.

It should be relatively straightforward to at least make the fixed list of
known browsers a property.

Ingo

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Emil

Ivov
Sent: Mittwoch, 11. Dezember 2013 12:52
To: Jitsi Developers
Cc: Florian J. Lorenz
Subject: Re: [jitsi-dev] Default software after file transfer
I think we currently use Java to figure this out since we don't need to
worry about the different platforms.

If anyone would like to contribute an improvement there, that would
definitely be welcome!

Emil

Thanks for the quick answer.

Do you know if there is a reason, why Jitsi does not use the system
defaults? Or is it just so with Linux / KDE? - i haven't tried it with
another OS yet.

Because except of this issue Jitsi is my favorite IM/VVoIP-App, since
Kopete is outdated and Telepathy is not really ready to use yet.

Greetings,
Florian.

Vom Dienstag, 10. Dezember 2013:

It is not currently possible to change this.

Emil

Hello,

i have a question regarding to Jitsis behaviour after a file transfer.

After a file transfer is completed, you have the possibility of opening
the file or the file-path out of Jitsi.

Is there a possibility to change the default software?

Firefox is my default Browser, but whenever i open a link from Jitsi,

it

opens Konqueror (my system opens Firefox out of every other

application,

···

-----Original Message-----
On 10.12.13, 20:02, Florian J. Lorenz wrote:

On 09.12.13, 19:29, Florian J. Lorenz wrote:

like Okular, LibreOffice).

Dolphin is my default File Manager, but whenever i open a file from
Jitsi, it opens Gwenview.

In case of pictures it opens GIMP instead of Gwenview, etc...

I am running two laptops with openSUSE KDE 13.1.

I hope, you could help me with this :slight_smile:

Greetings,
Florian.

_______________________________________________
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


#6

Actually, the most common way to handle this on Linux at the moment is
xdg-open.

Regards,
Philipp

···

On Wed, 11 Dec 2013 14:39:35 +0200 Kertesz Laszlo <laszlo.kertesz@gmail.com> wrote:

Florian J. Lorenz wrote:
> Thanks for the quick answer.
>
> Do you know if there is a reason, why Jitsi does not use the system
> defaults? Or is it just so with Linux / KDE? - i haven't tried it
> with another OS yet.
>
> Because except of this issue Jitsi is my favorite IM/VVoIP-App,
> since Kopete is outdated and Telepathy is not really ready to use
> yet.
>
> Greetings,
> Florian.
>

I have the same issue. On Linux there are more mechanisms that are
used to assign the default program for a specified link or file type.
There is a mimetype file list in text format, there are the
predefined browsers in the alternatives mechanism. I had the same
issue with Chrome opening all the time instead of Seamonkey which i
use as my main browser. The solution was to set the
gnome-www-browser, x-www-browser to point to my seamonkey binary. It
seems that Jitsi uses these to determine the browser (or relies on
some Java mechanism that uses these).

And thats not ok since not all DEs use these links. Also the default
openers for other stuff like folders or files are interpreted
differently too. I had to manually edit the mimetypes files.


#7

Hello,

Jitsi uses about 2x memory on amd64 builds on Linux (Debian 64 bit) compared to the i386 builds. Since the i386 version uses quite some memory (~200 MB resident), the amd64's ~400 MB resident size is over-the-top high for a messenger app which for most of the time does nothing.

But if i edit the jitsi launcher script /usr/bin/jitsi and modify it to use 256 MB max as it does on i386:

if [ $ARCH -eq 32 ]
then
     CLIENTARGS="-client -Xmx256m"
fi

to

#if [ $ARCH -eq 32 ]
#then
     CLIENTARGS="-client -Xmx256m"
#fi

The memory usage will be about the same (~200MB on amd64) and i hadnt noticed any (new)problems.

Is there a practical reason for these arguments left disabled on amd64 which warrant this high memory usage?


#8

Hello,

0001-Adds-the-net.java.sip.communicator.impl.browserlaunc.patch (7.58 KB)

···

On 12/11/13 2:17 PM, Ingo Bauersachs wrote:

Actually, the BrowserLauncherService tries a fixed list of browsers on
Linux. Mac uses a deprecated API (from JDIC?) and Windows a shell-call.

It should be relatively straightforward to at least make the fixed list of
known browsers a property.

Ingo

I have a patch for this (attached). I only did a very quick test, so
I'll wait for the stable release before committing.

Regards,
Boris


#9

Basicly the reasoning is that every variable uses twice the space in
64bit envs, still jitsi 200 mb on x32 is just too much.

- --
Yannik V�lker

···

Am 17.12.2013 08:24, schrieb Kertesz Laszlo:

Hello,

Jitsi uses about 2x memory on amd64 builds on Linux (Debian 64
bit) compared to the i386 builds. Since the i386 version uses quite
some memory (~200 MB resident), the amd64's ~400 MB resident size
is over-the-top high for a messenger app which for most of the time
does nothing.

But if i edit the jitsi launcher script /usr/bin/jitsi and modify
it to use 256 MB max as it does on i386:

if [ $ARCH -eq 32 ] then CLIENTARGS="-client -Xmx256m" fi

to

#if [ $ARCH -eq 32 ] #then CLIENTARGS="-client -Xmx256m" #fi

The memory usage will be about the same (~200MB on amd64) and i
hadnt noticed any (new)problems.

Is there a practical reason for these arguments left disabled on
amd64 which warrant this high memory usage?


#10

Actually, the BrowserLauncherService tries a fixed list of browsers on
Linux. Mac uses a deprecated API (from JDIC?) and Windows a shell-call.

It should be relatively straightforward to at least make the fixed list

of

known browsers a property.

Ingo

I have a patch for this (attached). I only did a very quick test, so
I'll wait for the stable release before committing.

Thanks!

A few comments:
- The config service is always there, no need to check for null
- Instead of throwing an exception that a browser wasn't found, I'd just log
it and do nothing
- The list of browsers that is currently hard-coded into the array could be
moved to jitsi-defaults.properties (that's what it is for after all)
- This default list should probably be prefix by "xdg-open" as suggested by
Phillip

Regards,
Boris

Ingo

···

On 12/11/13 2:17 PM, Ingo Bauersachs wrote:


#11

Actually, the BrowserLauncherService tries a fixed list of browsers on
Linux. Mac uses a deprecated API (from JDIC?) and Windows a shell-call.

It should be relatively straightforward to at least make the fixed list

of

known browsers a property.

Ingo

I have a patch for this (attached). I only did a very quick test, so
I'll wait for the stable release before committing.

Thanks!

Just a quick one:

A few comments:
- The config service is always there, no need to check for null

The low cost of a null check is easily outweighed buy the simplicity
of an otherwise very useful practice: "always check services for
null".

Emil

···

On Sat, Dec 28, 2013 at 4:57 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

On 12/11/13 2:17 PM, Ingo Bauersachs wrote:


#12

Hi, Ingo

Thanks for the comments!

Actually, the BrowserLauncherService tries a fixed list of browsers on
Linux. Mac uses a deprecated API (from JDIC?) and Windows a shell-call.

It should be relatively straightforward to at least make the fixed list

of

known browsers a property.

Ingo

I have a patch for this (attached). I only did a very quick test, so
I'll wait for the stable release before committing.

Thanks!

A few comments:
- The config service is always there, no need to check for null

It does make the code a bit less readable. I don't mind removing it if
you insist, but I'd rather keep it as it's not immediately obvious to me
why it's not necessary.

- Instead of throwing an exception that a browser wasn't found, I'd just log
it and do nothing

Updated. I think ideally it should be an exception that goes up to the
GUI, but that's another change.

- The list of browsers that is currently hard-coded into the array could be
moved to jitsi-defaults.properties (that's what it is for after all)

Oh, that's handy! Patch updated. Can we always rely on
jitsi-defaults.properties being there?

- This default list should probably be prefix by "xdg-open" as suggested by
Phillip

Added.

Regards,
Boris

0001-Adds-the-net.java.sip.communicator.impl.browserlaunc.patch (8.81 KB)

···

On 12/28/13 4:57 PM, Ingo Bauersachs wrote:

On 12/11/13 2:17 PM, Ingo Bauersachs wrote:


#13

Yannik V�lker wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello,

Jitsi uses about 2x memory on amd64 builds on Linux (Debian 64 bit)
compared to the i386 builds. Since the i386 version uses quite some
memory (~200 MB resident), the amd64's ~400 MB resident size is
over-the-top high for a messenger app which for most of the time
does nothing.

But if i edit the jitsi launcher script /usr/bin/jitsi and modify
it to use 256 MB max as it does on i386:

if [ $ARCH -eq 32 ] then CLIENTARGS="-client -Xmx256m" fi

to

#if [ $ARCH -eq 32 ] #then CLIENTARGS="-client -Xmx256m" #fi

The memory usage will be about the same (~200MB on amd64) and i
hadnt noticed any (new)problems.

Is there a practical reason for these arguments left disabled on
amd64 which warrant this high memory usage?

Basicly the reasoning is that every variable uses twice the space in
64bit envs, still jitsi 200 mb on x32 is just too much.

Ok, but why its working with the -client -Xmx256m arguments just as well on 64bit? Are there some corner cases where something might fail?
I had ~ 1 hour long 2-way video chats over google talk and it worked with no issues.

BTW have 5 active accounts configured - 1 SIP (Asterisk server), 1 local SIP, 1 Google Talk, 1 Yahoo and 1 Facebook.

Here is the output from top, look at the RES (resident size) - this is with the default /usr/bin/jitsi, jitsi is the only java app running:

top - 09:00:58 up 2 days, 1:24, 6 users, load average: 0.31, 0.31, 0.22
Tasks: 187 total, 2 running, 185 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.7 us, 0.4 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 6064684 total, 5907796 used, 156888 free, 626604 buffers
KiB Swap: 6828756 total, 37148 used, 6791608 free, 2470956 cached

   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16075 laca 20 0 2095m 668m 49m S 0.0 11.3 62:52.40 Seamonkey
  5939 laca 20 0 4329m 467m 23m S 1.0 7.9 0:23.25 java

And here it is with the -client -Xmx256m options enabled:

top - 09:02:43 up 2 days, 1:25, 6 users, load average: 0.21, 0.26, 0.22
Tasks: 187 total, 2 running, 185 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.3 us, 0.9 sy, 0.0 ni, 94.3 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 6064684 total, 5600860 used, 463824 free, 623656 buffers
KiB Swap: 6828756 total, 37224 used, 6791532 free, 2426088 cached

   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16075 laca 20 0 2079m 671m 49m S 7.6 11.3 62:56.28 Seamonkey
  3757 root 20 0 1686m 238m 3948 S 0.3 4.0 4:51.66 qemu-system-x86
  6182 laca 20 0 3058m 211m 22m S 3.6 3.6 0:18.79 java

Jitsi uses ~200 MB (like the second top output) since forever on my 32 bit system, what do you guys use to measure memory usage?

···

Am 17.12.2013 08:24, schrieb Kertesz Laszlo:

- -- Yannik V�lker -----BEGIN PGP SIGNATURE----- Version: GnuPG
v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSsO+QAAoJEDqk81AiCyXKM8kP/2A0IUx6wG5olxibvhFQjhp3
0hOJXCQVqvEZWIRa0CQ/XBz650uK1hOtECaK/1gkNVBzbyxAOW974iVRUxuJkhok
CgeKYNrDY6l2bjdHvFG8F6GLj/GqAHXdsBIA8xpCAW5VT6BqfADhYvCLunXzAh1A
y+CD0s20SMZhYt+dWdTonPbgxFuLTTSP33jcTYzPsalCRpUBd3bGtXeixcQu4Pzt
+rhRu9YSA8IRtfvsMwAGQ404Qr+ZkBtEy5GLxiAHNZmqDHG8tY1vkb35FVU/GvVu
rLyDYOTGYyC0e1T+IHXbnN7BpyqcQXBk/WNrcVC6Hc1sYcmRlBlUntWTIdjF0HlL
bHasWEsjlFQ1VTvqzW6iyZV8bPCnY6byaSq+B32w5A1xbJzFDM4NMNrlXbo+E/L8
3n3JdGyfDgV9amHKjGTPdvH60yriVXTB12w2YKH8lpb0qUw60DdGM1b1d2JPZdtq
dH16GnLxeB8GyW9HzJbsOGJbqLCA6F1lmkFVOMrta1wFnDJIH0La1q/VMM/omEWw
ZYw1uoUc7F6VRZwb+DBhFG/i6y4zZdi76bFDgBGAXDz5VehtEoera6lfA/acCuUj
a805emidJ4hyrhOVbGtiV4iGtyYFj2pBRTtbn9o1eCCstm/7ovFvK3vRnlr8BM0m
rz3EBzW3nLfSZaH4Ra3V =sBfu -----END PGP SIGNATURE-----

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

--
O zi buna,
Kertesz Laszlo


#14

Actually, the BrowserLauncherService tries a fixed list of browsers on
Linux. Mac uses a deprecated API (from JDIC?) and Windows a shell-call.

It should be relatively straightforward to at least make the fixed
list of known browsers a property.

Ingo

I have a patch for this (attached). I only did a very quick test, so
I'll wait for the stable release before committing.

Thanks!

A few comments:
- The config service is always there, no need to check for null

It does make the code a bit less readable. I don't mind removing it if
you insist, but I'd rather keep it as it's not immediately obvious to me
why it's not necessary.

Do it as you feel it is best.

- Instead of throwing an exception that a browser wasn't found, I'd
just log it and do nothing

Updated. I think ideally it should be an exception that goes up to the
GUI, but that's another change.

True, but that would require either handling of a failure at each and every
place where we open a URL or sending an alert to the notification service.
I'm not sure if this is worth it. If links don't open, taking a look into
the logs is probably not too much of an effort.

- The list of browsers that is currently hard-coded into the array could

be

moved to jitsi-defaults.properties (that's what it is for after all)

Oh, that's handy! Patch updated. Can we always rely on
jitsi-defaults.properties being there?

Yes. That's the whole idea of that file. Over time, all currently hardcoded
should eventually go into it.

It will also completely replace defaults.properties that are currently being
access through the resources service, avoiding cluttered constructs like "if
!config then if !res-default then hard-default else res-default else
config". Most stuff in defaults.properties is GUI however, so I figured it's
not worth the effort when we're working on a new GUI anyway.

- This default list should probably be prefix by "xdg-open" as suggested

by

Phillip

Added.

Regards,
Boris

Ingo

···

On 12/28/13 4:57 PM, Ingo Bauersachs wrote:

On 12/11/13 2:17 PM, Ingo Bauersachs wrote:


#15

FYI, Oracle says the following with respect to the -client option:

A 64-bit capable JDK currently ignores this option and instead uses
the Java Hotspot Server VM.

···

2013/12/18 Kertesz Laszlo <laszlo.kertesz@gmail.com>:

Ok, but why its working with the -client -Xmx256m arguments just as well on
64bit?


#16

Hello,

Sorry for the delay, I've committed this:
https://github.com/jitsi/jitsi/commit/85c52a2753e5023c36c0addc35c725ac30d7adbd

As noted by Julian Erhard[1], previously the *last* working browser that
worked was used. Now the first one is used. I've re-aranged the list
somewhat to keep the generic "xdg-open" and "gnome-open" on top:
xdg-open
gnome-open
iceweasel
firefox
chromium-browser
google-chrome
opera
konqueror
epiphany
mozilla
netscape

To override the list, something like this can be added to
.jitsi/sip-communicator.properties:
net.java.sip.communicator.impl.browserlauncher.LINUX_BROWSERS="chromium-browser:/opt/custom-firefox-install/bin/firefox"

Regards,
Boris

[1] http://lists.jitsi.org/pipermail/dev/2014-January/019509.html


#17

Lyubomir Marinov wrote:

Ok, but why its working with the -client -Xmx256m arguments just as well on
64bit?

FYI, Oracle says the following with respect to the -client option:

A 64-bit capable JDK currently ignores this option and instead uses
the Java Hotspot Server VM.

Ok, i just commented out those lines there, might be the -client option is ignored and then it doesnt really matter.

But the -Xmx256m argument certainly isnt ignored (look at the previous mail where i included 2 "top" snippets, both were taken on the same 64 bit machine). And it does make Jitsi use half memory and i havent seen any adverse effects.
Are or might be any?
If not, whats the reasoning behind leaving it off in the 64 bit builds?

PS 400+ megs of used memory certainly isnt something i would call reasonable for a messenger, even 200 is high-ish but since its Java involved i assume its reasonable to accept some overhead.

···

2013/12/18 Kertesz Laszlo <laszlo.kertesz@gmail.com>:

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

--
O zi buna,
Kertesz Laszlo


#18

Thanks Boris, this looks sensible to me.

Regards,
Philipp

···

On Wed, 15 Jan 2014 10:09:36 +0100 Boris Grozev <boris@jitsi.org> wrote:

Hello,

Sorry for the delay, I've committed this:
https://github.com/jitsi/jitsi/commit/85c52a2753e5023c36c0addc35c725ac30d7adbd

As noted by Julian Erhard[1], previously the *last* working browser
that worked was used. Now the first one is used. I've re-aranged the
list somewhat to keep the generic "xdg-open" and "gnome-open" on top:
xdg-open
gnome-open
iceweasel
firefox
chromium-browser
google-chrome
opera
konqueror
epiphany
mozilla
netscape

To override the list, something like this can be added to
.jitsi/sip-communicator.properties:
net.java.sip.communicator.impl.browserlauncher.LINUX_BROWSERS="chromium-browser:/opt/custom-firefox-install/bin/firefox"

Regards,
Boris

[1] http://lists.jitsi.org/pipermail/dev/2014-January/019509.html

--
JID: murks@jit.si