Release Candidate 3.0 status/issues

Current Release Candidate: 10

For system compatibility on release, please use the system_tray_3.0.jar -- this file is the same format that the release will be in. For all-in-one "FAT" jars, use the RCx.jars.

RC10: Fixed issue/added support for Swing UI menu/entry customization independent of system L&F.

RC9: Removed getNative() and getSwing(). There is only get(), which will choose native,Swing, or AWT depending on OS. This can be customized (see readme)

RC8: Fixed crash on Windows java 32bit with injecting bytecode.

RC7: Small API changes from RC6 -> RC7: SystemTray.get() is now SystemTray.getSwing() to indicate it's menu type (Similarly to getNative()), and to indicate that there is no library preference between the two different methods.

The Release Candidate downloads is released as a "all-in-one" jar, for a variety of different tray types and configurations. Please note that SWT testing will require you to download the SWT native library and add it to the classpath when you launch the jar. If you use SWT, you should be familiar with this, otherwise don't worry about it.

There shouldn't be any issues for any of the OS' listed in the Compatibility Matrix. If you are testing this and your OS isn't listed, please open a new issue for it.

Finally, the jars can be tested via java -jar SystemTray_RC2_normal.jar (as an example).

EDIT: I've cleaned up this thread a bit, it was becoming big. After the Release Candidate passes, this issue will be closed.

Problems and Restrictions

JavaFX uses GTK2 for Java <8, and GTK2 or GTK3 for Java 9+. We try to autodetect this, and are mostly successful. In some situations where it doesn't work. Please set SystemTray.FORCE_GTK2=true;, or to change JavaFX (9+), use -Djdk.gtk.version=3 to solve this.
SWT can use GTK2 or GTK3. If you want to use GTK2 you must force SWT into GTK2 mode via System.setProperty("SWT_GTK3", "0"); before SWT is initialized and only if there are problems with the autodetection, you can also set SystemTray.FORCE_GTK2=true;.
AppIndicators under Ubuntu 16.04 (and possibly other distro's) will not work as a different user (ie: as a sudo'd user to root), since AppIndicators require a dbus connection to the current user's window manager -- and this cannot happen between different user accounts. There is no workaround.
MacOSX is a special snowflake in how it handles GUI events, and so there are some bizzaro combinations of SWT, JavaFX, and Swing that do not work together (see the Notes below for the details.)
Gnome3 (Fedora, Manjaro, Arch, etc) environments by default do not allow the SystemTray icon to be shown. This has been worked around (it will be placed next to the clock) for most Gnome environments, except for Arch linux. Another workaround is to install the Top Icons plugin plugin which moves icons from the notification drawer (it is normally collapsed) at the bottom left corner of the screen to the menu panel next to the clock.

Compatibility Matrix

✓=supported, -= not supported, += see notes

OS	Swing	JavaFX	SWT
XUbuntu 16.04	✓	✓	✓
Ubuntu 16.04	✓	+	✓
UbuntuGnome 16.04	✓	+	✓
Fedora 23	✓	✓	✓
Fedora 24	✓	✓	✓
Fedora 25	✓	✓	✓
Fedora 25 KDE	✓	✓	✓
LinuxMint 18	✓	✓	✓
Elementary OS 0.3.2	-	✓	✓
Elementary OS 0.4	-	✓	✓
Arch Linux + Gnome3	✓	✓	✓
FreeBSD 11 + Gnome3	✓	✓	+
Debian 8.5 + Gnome3	-	-	-
Debian 8.6 + Gnome3	-	-	-
MacOSx	✓	+	+
Win XP	✓	✓	✓
Win 7	✓	✓	✓
Win 8.1	✓	✓	✓
Win 10	✓	✓	✓

Notes:

Ubuntu 16.04+ with JavaFX require libappindicator1 because of JavaFX GTK and indicator panel incompatibilities. See more details.
MacOSX JavaFX (Java7) is incompatible with the SystemTray by default. See issue details.
- To fix this do one of the following
  - Upgrade to Java 8
  - Add : -Djavafx.macosx.embedded=true as a JVM parameter
  - Set the system property via System.setProperty("javafx.macosx.embedded", "true"); before JavaFX is initialized, used, or accessed. NOTE: You may need to change the class (that your main method is in) so it does NOT extend the JavaFX Application class.
MacOSX SWT + Swing menus are incompatible with each other by (Apple's) design for all versions of Java. What will happen in this combination is that the Swing EDT hangs. The only solution is to use native menus in this specific combination; which is automatically handled during SystemTray initialization.
SWT for FreeBSD builds do not exist.
ElementaryOS does some really bizzare things when it comes to System Tray icons/menus, and as such - the Swing menu implementation is not supported on that OS. The library will auto-switch to a native menu in this situation.

@dorkbox

@dorkbox will this be a drop-in replacement for Java's existing ActionListeners? Also, would you consider an AWT wrapper addition as optional parameter?

If so, I think we can go live with this 3.0 in January which would give you real-world test results. The windows icon fix alone is reason to implement it. We're currently integrating version 2.2.0, but if you've already written the wrappers, 3.0 is a much more attractive option.

@tresf

@tresf what do you mean by AWT wrapper as a parameter? For adding menu entries? I'm a little confused.

As for using ActionListeners, yea - that could probably happen. It might be a little tricky since for linux/mac, I'm basically writing C code in Java to muck around in GTK/AppIndicator libraries (literally rewrote the implementation of tray icons from scratch, using JNA).

How would you imagine it happening? Just adding a new Menu Entry, but passing it an ActionListener instead?

@dorkbox

@dorkbox sorry I'm mixing around terms... I meant JMenuItem wrapper as AWT is natively supported on Apple and the menu looks perfect, but it will fragment code. For this reason, we wrote a small AWT wrapper with a recursive MenuItem function to essentially destroy the swing JMenuItems and create an awt MenuItem equivalent. This maps mneumonics and recurses through submenus. Thus, someone who wants native menus on Mac can have them without fragmenting the codebase.

@tresf

@tresf Ahh. Yea, I can probably do something like that. Would you be willing to license your wrapper/recursive function as Apache 2.0 for me, that way I don't have to re-do what you've already done?
e: formatting/grammar

We're working to integrate 2.2.0 now, but what would make this integration easier is a method for wrapping a JPopupMenu or JMenu into the appropriate platform-specific workaround. This way the listener code won't have to be fragmented. It would truly be a one-size-fits-all solution.

From what I understand AppIndicator has its own caveats (listeners are bound to a string value) but we'll be wrapping all of this anyway (probably HashMap the strings and throw exception if a duplicate exists). The swing objects are pretty inexpensive to construct so it would allow GUI developers to code the way they're used to while allowing the library to to the heavy lifting (so to speak).

What I'm hoping for is that application developers don't have to do any OS/platform workarounds... :D

willing to license your wrapper/recursive function as Apache 2.0 for me that way I don't have to re-do what you've already done?

Consider this written permission to release AWTMenuWrapper.java and ClassicTrayIcon.java -- which I am the sole author -- in whole, part of modified form under the Apache 2.0 license.

willing to license your wrapper/recursive function as Apache 2.0 for me that way I don't have to re-do what you've already done?

Consider this written permission to release AWTMenuWrapper.java and ClassicTrayIcon.java -- which I am the sole author -- in whole, part of modified form under the Apache 2.0 license.

Awesome. I'll go about adding that functionality as soon as I get some bugs worked out.

@dyorgio

@dyorgio I should also mention, this won't work with gnome-shell installed AFTER Ubuntu is installed... all I know is that it has something to do with Unity messing things up. It does work flawlessly with UbuntuGnome though.

@dyorgio

@dyorgio reproducing the error/crash. Now to figure out what's going on...

@dorkbox

@dorkbox tks for your hard work! :)
What do you think to create a incredible massive verbose debug version to us?
It can help to find the complete stack trace of lib on our systems.

@dyorgio

@dyorgio I have some more detailed library debugging (currently off). I'll tie it into the general "debug" flag, so you can see what's getting checked/loaded during started.

Just as a note, there have been some slight API changes, I think for the better. The changes (for the most part) have all been to simpler method names, IE: a change from SystemTray.getSystemTray() to SystemTray.get(). It's not a huge difference, but makes the calls less verbose.

Additionally, I have not been able to test (or debug) what is wrong with JavaFX on MacOSx. I suspect it might be a threading issue -- or, as I've read online, JavaFX on a Mac can only run on physical hardware (there are problems with it running in a VM.).

https://bugs.openjdk.java.net/browse/JDK-8154148
http://stackoverflow.com/questions/34016061/javafx-on-mac-os-x-yosemite-crashes

@dorkbox

@dorkbox we use JavaFX + Oracle Java 8 and when testing on ElementaryOS 0.3.2 x64 and RC5 crashes when JavaFX is invoked. Details available here: qzind/tray#149 (comment)

... Edt: Also a minor cosmetic issue (same OS + Java)... I notice a significant flicker when a submenu pops-up. It draws a black box about 30% larger than the size of the submenu, then draws the submenu. Native submenus don't seem to draw this artifact. I'm not sure if you've noticed this on any other platforms.

@Vzor-

I do ID detection for most linux OS types, depending on the desktop env, and it looks like ElementaryOS changed their OS ID between releases.... I'll investigate further.

Additionally, the artifact you see is because ElementaryOS changed the threading model for GUI event dispatch (beats me why.. but it exposed a number of bugs that @Vzor- helped find/fix). The work-around is to force native menus (and emit a warning) -- which is what happens for 0.4

I'll update the logic to choose the appropriate menu type when the SystemTray loads.

@tresf

@tresf Also, FreeBSD doesn't work -- I'm fixing it right now as well.

@dorkbox

@dorkbox testing Debian Jessie 8.5 x64 + Gnome3, I don't see the icon in the bottom drawer like I'd expect. Please let me know if you'd prefer this tracked in a separate bug report.

16:24:11.654 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - GTK: libgtk-3.so.0
16:24:11.656 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Is the system already running GTK? false
16:24:11.784 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - OS: Linux
16:24:11.784 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Arch: amd64
16:24:11.784 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_111
16:24:11.785 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Is AutoTraySize? true
16:24:11.785 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Is JavaFX detected? false
16:24:11.785 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Is SWT detected? false
16:24:11.785 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Is using native menus? true
16:24:11.785 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Forced tray type: AutoDetect
16:24:11.785 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - FORCE_GTK2: false
16:24:11.806 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Currently using the 'GNOME' desktop
16:24:11.806 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Currently using the 'default' session type
16:24:11.846 [AWT-EventQueue-0] WARN dorkbox.systemTray.SystemTray - Unable to determine the system window manager type. Falling back to GtkStatusIcon.
16:24:11.855 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Checking scaling factor for GTK environment, should start with 'uint32', value: 'uint32 0'
16:24:11.866 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Scaling Factor factor is '0', tray icon size is '16'.
16:24:11.866 [AWT-EventQueue-0] DEBUG dorkbox.systemTray.SystemTray - Scaling Factor factor is '0', tray menu size is '16'.
16:24:11.882 [GTK Native Event Loop] DEBUG dorkbox.systemTray.SystemTray - Running GTK Native Event Loop
16:24:12.109 [AWT-EventQueue-0] INFO dorkbox.systemTray.SystemTray - Successfully Loaded: _GtkStatusIconNativeTray

@tresf

@tresf Debian 8.5 and 8.6 don't appear to support tray icons at all: neither GtkStatusIcon nor AppIndicator. The error i'm getting in the gnome-shell logs is tray.STANDARD_TRAY_ICON_IMPLEMENTATIONS is undefined

@dorkbox

@dorkbox Fair enough. Perhaps we should probably put a note about it in the compat chart.

I just finished reading this: https://wiki.gnome.org/Design/Whiteboards/StatusIcons

I have elementaryOS 0.3.2 and FreeBSD 11 + Gnome3 working, I'll update the matrix. Should I make another RC?

Fixed issues with GTK checkboxes signaling the callback when changing the checked state. This no longer happens. Additionally, there is an API change from SystemTray.get() -> SystemTray.getSwing()`.

I expect this to be the final release candidate, pending feedback from QZ-Tray.

@Vzor-

The last remaining issue was #45 before the 3.0 release. Just checking with @Vzor- and @tresf to verify.

It looks good now.

3.0 is now released. Available under Github releases and maven.

Dependency bug:

I needed to include dependency on my project:

<dependency>
    <groupId>javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.12.1.GA</version>
</dependency>

The lib doesn't contains any maven dependency information...

Ah, I'll add this. Thanks for the info.

Navigation Menu

Release Candidate 3.0 status/issues #22

Current Release Candidate: 10

Problems and Restrictions

Compatibility Matrix

Notes:

14 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Release Candidate 3.0 status/issues #22

Description

Current Release Candidate: 10

Activity

dorkbox commented on Sep 26, 2016

Problems and Restrictions

Compatibility Matrix

Notes:

tresf commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

tresf commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

tresf commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

tresf commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

dyorgio commented on Sep 26, 2016

dorkbox commented on Sep 26, 2016

dorkbox commented on Oct 5, 2016

14 remaining items

tresf commented on Dec 29, 2016

dorkbox commented on Dec 29, 2016

dorkbox commented on Dec 29, 2016

tresf commented on Dec 29, 2016

dorkbox commented on Dec 29, 2016

tresf commented on Dec 29, 2016

dorkbox commented on Dec 29, 2016

dorkbox commented on Jan 21, 2017

dorkbox commented on Feb 19, 2017

Vzor- commented on Feb 20, 2017

dorkbox commented on Feb 21, 2017

dyorgio commented on Feb 21, 2017

dorkbox commented on Feb 21, 2017

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions