[jitsi-users] Jitsi and Kde5 systray problem


#1

Hello,

since a week or two I can't use Jitsi anymore: it starts up, but gui seems stuck. I use Debian Stretch and Jitsi 2.4.4997-1.2 (by the way: any idea when a new version for Debian will be packed? And for Android?). All worked well since months. The problem seem tied to new Kde 5 systray:

$ jitsi &

Thanks for your attention,
  Matteo


#2

disclaimer: i am also just a user so far

i have the same problem on Trisquel Linux'es default desktop

problem:
jitsi assumes that there will always be a working systray, compatible with
java.awt.SystemTray.
which is a bogus/bad assumption according to the javadoc for that class:
https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
"On some platforms the system tray may not be present or may not be
supported, in this case getSystemTray() throws
UnsupportedOperationException. To detect whether the system tray is
supported, use isSupported()."

solution:
i think, jitsi should be changed to have a non-systray-mode it can fall
back. additionally, it could also be a config option for people that
dislike systrays, even if their desktop supports it. in that
non-systray-mode the main GUI is always visible when jitsi is running, and
when it is closed, jitsi is close dwith it.

if i get an ok for that solution from some dev(s) that would accept it, i
could start implementing it.


#3

I tried to set the following option to false:

*net.java.sip.communicator.impl.systray.showApplication*=*false*

in ~/.jitsi/sip-communicator.properties, but the result was that the gui
didn't even show up. Also, in this case Jitsi was "alive", bacause for
example it opened a window when a Jabber message arrived, but the
window was blank.

Thanks,
  Matteo


#4

50 cents:

In a non systray cause, you could just iconify the window by removing
the gui elements and the border ( i.e. borderless window ), adding a
small icon to it, minimize the window. If it gets clicked or maximized,
you revert this. You just have to remember the windowpositions where it
was moved while iconified.

Marius

···

Am 05.01.2016 um 11:34 schrieb Robin Vobruba:

disclaimer: i am also just a user so far

i have the same problem on Trisquel Linux'es default desktop

problem:
jitsi assumes that there will always be a working systray, compatible
with java.awt.SystemTray.
which is a bogus/bad assumption according to the javadoc for that class:
https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
"On some platforms the system tray may not be present or may not be
supported, in this case getSystemTray() throws
UnsupportedOperationException. To detect whether the system tray is
supported, use isSupported()."

solution:
i think, jitsi should be changed to have a non-systray-mode it can
fall back. additionally, it could also be a config option for people
that dislike systrays, even if their desktop supports it. in that
non-systray-mode the main GUI is always visible when jitsi is running,


#5

Thanks Robin, I'd happily review a pull request that makes the tray optional.
The way this should be done is IMO:
- Check the is supported flag
- Check a config option to disable a tray if the user dislikes it (optional, depends on your time)
- Check for exceptions during initialization

Then, if the tray is unavailable/disabled:
- Minimize to the taskbar (or whatever the platform calls it). Optionally make minimizing/exiting a config option with default being minimizing.
- The message indicating that Jitsi continues running might need to be adapted (english only)

Please familiarize yourself with the coding guidelines and sign the CLA before you submit the pull request.

Thanks,
Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 05.01.2016, at 23:35, Robin Vobruba <mls.robin.vobruba@gmail.com> wrote:

disclaimer: i am also just a user so far

i have the same problem on Trisquel Linux'es default desktop

problem:
jitsi assumes that there will always be a working systray, compatible with java.awt.SystemTray.
which is a bogus/bad assumption according to the javadoc for that class:
https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
"On some platforms the system tray may not be present or may not be supported, in this case getSystemTray() throws UnsupportedOperationException. To detect whether the system tray is supported, use isSupported()."

solution:
i think, jitsi should be changed to have a non-systray-mode it can fall back. additionally, it could also be a config option for people that dislike systrays, even if their desktop supports it. in that non-systray-mode the main GUI is always visible when jitsi is running, and when it is closed, jitsi is close dwith it.

if i get an ok for that solution from some dev(s) that would accept it, i could start implementing it.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#6

would that not be very counter-inuitive for users? not to mention that they
probably do simply not want any systray-like system, if their desktop does
not support it, or they disabled it.
it personally would hate it if an application re-invents things in a
non-standard way, and effectively ignores my preferences, which i
configured through my OS settings.

···

2016-01-05 12:39 GMT+01:00 Cyborg <cyborg2@benderirc.de>:

Am 05.01.2016 um 11:34 schrieb Robin Vobruba:
> disclaimer: i am also just a user so far
>
> i have the same problem on Trisquel Linux'es default desktop
>
> problem:
> jitsi assumes that there will always be a working systray, compatible
> with java.awt.SystemTray.
> which is a bogus/bad assumption according to the javadoc for that class:
> https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
> "On some platforms the system tray may not be present or may not be
> supported, in this case getSystemTray() throws
> UnsupportedOperationException. To detect whether the system tray is
> supported, use isSupported()."
>
> solution:
> i think, jitsi should be changed to have a non-systray-mode it can
> fall back. additionally, it could also be a config option for people
> that dislike systrays, even if their desktop supports it. in that
> non-systray-mode the main GUI is always visible when jitsi is running,

50 cents:

In a non systray cause, you could just iconify the window by removing
the gui elements and the border ( i.e. borderless window ), adding a
small icon to it, minimize the window. If it gets clicked or maximized,
you revert this. You just have to remember the windowpositions where it
was moved while iconified.

Marius

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


#7

thanks ingo for the heads-up and the clear idea! :slight_smile:
makes sense to me, but the default being minimizing.
that would mean, that a user that disables sys-tray, or has no working one
on his system, when trying to close jitsi, would go to the 3 buttons on top
of the main window, which are minimize, maximize and exit, he clicks on
exit, and then jitsi minimizes. if this user was me, i would be annoyed,
also if there is a message telling me it will continue running. if i want
to minimize, i would click on minimize. it's not jitsis task to decide that
it is too important to not be running in the background, or that it is
special and should not adhere to the desktop/GUI standards the user is used
to.
so i would make the default exit, and if that is not acceptable for you, i
would at least ask the user the first time he clicks on the [x], whether he
wants to minimize or exit, and then also use that as default. but as said,
i think there is no reason to have 3 buttons of which 2 have the same
effect.
i guess the minimizing option might be chosen by users that are used to use
jitis on a system with sys-tray and like that way, while all others would
probably choose the exit option, and as many of them might be newbs, and
maybe non-techies, i think we should not force them to first have even the
idea that this could be a config option, and then also find it.
please enlighten me if i am wrong (can;t hurt, cause maybe later on others
might have the same questions anyway). :slight_smile:
will read the coding guidelines.
thanks again for the answer! :slight_smile:

···

2016-01-06 4:40 GMT+01:00 Ingo Bauersachs <ingo@jitsi.org>:

Thanks Robin, I'd happily review a pull request that makes the tray
optional.
The way this should be done is IMO:
- Check the is supported flag
- Check a config option to disable a tray if the user dislikes it
(optional, depends on your time)
- Check for exceptions during initialization

Then, if the tray is unavailable/disabled:
- Minimize to the taskbar (or whatever the platform calls it). Optionally
make minimizing/exiting a config option with default being minimizing.
- The message indicating that Jitsi continues running might need to be
adapted (english only)

Please familiarize yourself with the coding guidelines and sign the CLA
before you submit the pull request.

Thanks,
Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

On 05.01.2016, at 23:35, Robin Vobruba <mls.robin.vobruba@gmail.com> > wrote:

disclaimer: i am also just a user so far

i have the same problem on Trisquel Linux'es default desktop

problem:
jitsi assumes that there will always be a working systray, compatible with
java.awt.SystemTray.
which is a bogus/bad assumption according to the javadoc for that class:
https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
"On some platforms the system tray may not be present or may not be
supported, in this case getSystemTray() throws
UnsupportedOperationException. To detect whether the system tray is
supported, use isSupported()."

solution:
i think, jitsi should be changed to have a non-systray-mode it can fall
back. additionally, it could also be a config option for people that
dislike systrays, even if their desktop supports it. in that
non-systray-mode the main GUI is always visible when jitsi is running, and
when it is closed, jitsi is close dwith it.

if i get an ok for that solution from some dev(s) that would accept it, i
could start implementing it.

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

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


#8

The users that are used to system tray IMHO don't use the window
buttons as much as clicking on the tray icon itself -- for opening and
for closing. Also escape key for closing. Talking of which,
keybindings for opening and closing the main window will help a
lot.

Although I guess you are right too, about the minimize on close.

One more thing -- since GNOME 3 there are a lot of apps that omit the
tray functionality and now we have tools like Kdocker[0] which fix the
problem on all the non-gnome DEs. So having an option to disable
system tray icon will work on gnu/linux systems where the java tray
icon has some known issues and will allow people to just replace it
with a kdocker (in case of trouble).

Just my 2c on the usability, not the technical side you are discussing.

[0] https://github.com/user-none/KDocker

···

On Wed, 6 Jan 2016 08:40:06 +0100 Robin Vobruba wrote:

i guess the minimizing option might be chosen by users that are used
to use jitis on a system with sys-tray and like that way, while all
others would probably choose the exit option, and as many of them
might be newbs, and maybe non-techies, i think we should not force
them to first have even the idea that this could be a config option,
and then also find it.

--

Yasen Pramatarov
Lindeas Ltd. https://lindeas.com
'working on GNU/Linux ideas'
Professional Jitsi Meet services


#9

I'm fine with asking wether to minimze/close instead of just notifying. The point about not closing immediately are accidental clicks.

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 06.01.2016, at 20:42, Robin Vobruba <mls.robin.vobruba@gmail.com> wrote:

thanks ingo for the heads-up and the clear idea! :slight_smile:
makes sense to me, but the default being minimizing.
that would mean, that a user that disables sys-tray, or has no working one on his system, when trying to close jitsi, would go to the 3 buttons on top of the main window, which are minimize, maximize and exit, he clicks on exit, and then jitsi minimizes. if this user was me, i would be annoyed, also if there is a message telling me it will continue running. if i want to minimize, i would click on minimize. it's not jitsis task to decide that it is too important to not be running in the background, or that it is special and should not adhere to the desktop/GUI standards the user is used to.
so i would make the default exit, and if that is not acceptable for you, i would at least ask the user the first time he clicks on the [x], whether he wants to minimize or exit, and then also use that as default. but as said, i think there is no reason to have 3 buttons of which 2 have the same effect.
i guess the minimizing option might be chosen by users that are used to use jitis on a system with sys-tray and like that way, while all others would probably choose the exit option, and as many of them might be newbs, and maybe non-techies, i think we should not force them to first have even the idea that this could be a config option, and then also find it.
please enlighten me if i am wrong (can;t hurt, cause maybe later on others might have the same questions anyway). :slight_smile:
will read the coding guidelines.
thanks again for the answer! :slight_smile:

2016-01-06 4:40 GMT+01:00 Ingo Bauersachs <ingo@jitsi.org>:

Thanks Robin, I'd happily review a pull request that makes the tray optional.
The way this should be done is IMO:
- Check the is supported flag
- Check a config option to disable a tray if the user dislikes it (optional, depends on your time)
- Check for exceptions during initialization

Then, if the tray is unavailable/disabled:
- Minimize to the taskbar (or whatever the platform calls it). Optionally make minimizing/exiting a config option with default being minimizing.
- The message indicating that Jitsi continues running might need to be adapted (english only)

Please familiarize yourself with the coding guidelines and sign the CLA before you submit the pull request.

Thanks,
Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

On 05.01.2016, at 23:35, Robin Vobruba <mls.robin.vobruba@gmail.com> wrote:

disclaimer: i am also just a user so far

i have the same problem on Trisquel Linux'es default desktop

problem:
jitsi assumes that there will always be a working systray, compatible with java.awt.SystemTray.
which is a bogus/bad assumption according to the javadoc for that class:
https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
"On some platforms the system tray may not be present or may not be supported, in this case getSystemTray() throws UnsupportedOperationException. To detect whether the system tray is supported, use isSupported()."

solution:
i think, jitsi should be changed to have a non-systray-mode it can fall back. additionally, it could also be a config option for people that dislike systrays, even if their desktop supports it. in that non-systray-mode the main GUI is always visible when jitsi is running, and when it is closed, jitsi is close dwith it.

if i get an ok for that solution from some dev(s) that would accept it, i could start implementing it.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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

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


#10

The systray issue is different anyway. I.e. the java implementation has
problems using the gnome systray correctly,
falling back to a window with the systray icon on the desktop, instead
of the systray iconrow.

In other words, it's broken anyway. I personaly would like to have a
fallback mode like i discribed it, so that i can at least place the icon
where i like, and not whats defaulted in openjdk.

And if you do not want a systray at all, why not adding an option to it,
to disable it entirely ? Would solve both problems.

Marius

···

Am 05.01.2016 um 12:50 schrieb Robin Vobruba:

would that not be very counter-inuitive for users? not to mention that
they probably do simply not want any systray-like system, if their
desktop does not support it, or they disabled it.
it personally would hate it if an application re-invents things in a
non-standard way, and effectively ignores my preferences, which i
configured through my OS settings.


#11

yeah, i also mentioned it as an option. and i see that your solution also
makes sense, as you describe.
so.. i guess it makes sense to have the non-systray-mode as a config
option, and in case it is implemented already, and your way not yet, it
could be used as a fallback, in case Systray#isSupported() returns false,
even if not activated through the config option.

···

2016-01-05 13:17 GMT+01:00 Marius <jitsi@benderirc.de>:

Am 05.01.2016 um 12:50 schrieb Robin Vobruba:
> would that not be very counter-inuitive for users? not to mention that
> they probably do simply not want any systray-like system, if their
> desktop does not support it, or they disabled it.
> it personally would hate it if an application re-invents things in a
> non-standard way, and effectively ignores my preferences, which i
> configured through my OS settings.

The systray issue is different anyway. I.e. the java implementation has
problems using the gnome systray correctly,
falling back to a window with the systray icon on the desktop, instead
of the systray iconrow.

In other words, it's broken anyway. I personaly would like to have a
fallback mode like i discribed it, so that i can at least place the icon
where i like, and not whats defaulted in openjdk.

And if you do not want a systray at all, why not adding an option to it,
to disable it entirely ? Would solve both problems.

Marius

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