Work on supporting Linux DEs about fxtrayicon

[EasyG0ing1]

@dustinkredmond I agree ... the bottom line is, providing a system tray in an operating system is not the job of libraries like FXTrayIcon ... I would say that qualifies as outside the scope of the project. From what I understand, if you manage to install a system tray in Gnome, then AWT will pick it up and use it ... that's what I've read anyways. I did put in some effort to do just that, but got frustrated and gave up on it. I don't use Linux so it's not really a deal-breaker for me ☺

[EasyG0ing1]

@dustinkredmond I'll take a crack at it and let you know. I've got an Ubuntu 20 VM already set up.

[EasyG0ing1]

@dustinkredmond Apparently in Gnome 3.28 they dropped the system tray altogether. This is the recommended shell extension to bring it back, and based on one post I read, it works with Java. I'll see about testing it with FXTrayIcon.

https://github.com/phocean/TopIcons-plus

[EasyG0ing1]

As a matter of clarity, because Ubuntu 20.04 uses Gnome version 3.36.3, there is no SystemTray at all, as it was removed from Gnome back in version 3.28. This is why the getSystemTray() throws an exception. Using isSupported() would further clarify that SystemTray support is not available on the platform being used.

[EasyG0ing1]

I have verified that on a default installation of Ubuntu 20.04, performing the test

FXTrayIcon.isSupported()

returns false, and when I try to instantiate the FXTrayIcon class, I receive the exception thrown that says "SystemTray icons are not supported by the current desktop environment.", which is the custom exception written into the library based on the test

SystemTray.isSupported()

This is not a problem with awt. Gnome versions past 3.28 do not have a System Tray that Java can use and one must be added by the user. Installing a system tray into the user's environment should be outside of the scope of FXTrayIcon.

Perhaps modifying the error message to inform the user that they have other options for adding a system tray into their environment might be an idea? ... some language in it such as, "This desktop environment might not have a System Tray (ex Gome versions 3.28 or higher do not have a system tray) consider alternative methods for possibly adding a System Tray to your desktop environment then try running this application again".

Perhaps even making such an error a popup window that any GUI that JavaFX supports would display to the user, that way it would not be necessary to see a cumbersome error thrown in the terminal - such as when a user just double clicks on a jar file to run it. Any application that has FXTrayIcon compiled into it would then just throw a friendly GUI message to the user letting them know what's up and what they can do about it. Though an app developer should be testing their apps in their intended target environments ... albeit it is quite impossible to test every environment.

In the context of FXTrayIcon, this is the best option that I can think of.

[dustinkredmond]

@EasyG0ing1, there's definitely some way to access a tray-type functionality, at least in Ubuntu. See below example of the JetBrains Toolbox icon on Ubuntu 20.04. I'll do some digging today to see if I can figure out how they're doing this.

Even if it's only got limited support, I'll take it. 😄

[dustinkredmond]

I suppose we could programmatically install AppIndicator support, or check for it, then throw an error, but, I'm not sure if this is something that I want to do. Another repo on GitHub already does this, and it seems like one heck of a workaround. I'll give it some thought.

[EasyG0ing1]

@dustinkredmond Well isn't that interesting ... I'm not a big fan of re-inventing the wheel ... unless my invention will make the car go faster ... I might get the gumption to figure out how to add tray support to ubuntu ... and it might turn out to be a relatively easy thing to do once I figure it out ... but you know the open-source and especially Linux world ... the only time you can find clear and reliable instructions for doing anything ... is when anything is what most people do so that its popular enough that people invest time in writing quality instructions. It seems that tray support in Gnome isn't all that popular these days which might explain why they dropped it in the first place.

Even if I figure it out, we would still need to somehow offer some kind of a "how-to if you use Gnome version whatever whatever and higher..." unless we can dynamically add it somehow in the library ... but it just seems to me that if an operating system doesn't want a system tray ... why force the issue? I'm a firm believer in letting sentient beings live their lives autonomously in any way they see fit to live and if Gnome gender identifies without a System tray ... it almost seems wrong to force it to have one ... :-)

[EasyG0ing1]

@dustinkredmond ... But that Jetbrains tool box ... does have me curious. I wonder if they would just tell me how they did that if I asked.

[dustinkredmond]

@EasyG0ing1, as you said in your email. JetBrains advised that they use libappindicator over D-Bus.

This looks like a pain to implement for Java.
We'd have to do a few things.

1. Determine OS at runtime (Linux) as well as which Desktop Environment and version (GNOME, KDE, or a whole host of possible others).
2. Programatically install libappindicator support (assuming that a user doesn't have it already) or just assume that the library is already installed. Since FXTrayIcon is a library and not a bundled executable, I don't think we should do this, that can get messy quick.
3. Register the icon via C/C++ (either JNI or JNA) keeping in mind that some of the FXTrayIcon features aren't supported by AppIndicator (tooltips, for example)
4. Interface it all with Java to make it feel as smooth as development with Windows or MacOS is currently.

If this were a GUI with an executable, then this would be okay to do. We could have libappindicator as a dependency that gets resolved by APT or distribute as a snap package.

As much as I would have liked to have it, I think I'm going to throw in the towel on supporting Linux. There's just too many hacks to be written due to the huge amount of choices/customizability that is offered.

I will leave this issue open for a little while in case some brave soul has a clever solution, but unfortunately, with work and the few other side projects that I have, time and brain matter are at a premium right now. If popularity for FXTrayIcon continues to grow as it has up until this point, this may be an issue that's worth revisiting. I primarily use Linux at home, so I would love to see it. 😄

Thank you @EasyG0ing1 for your research on this.

[dpalic]

Trying to message here, but from other issue trackers on github assume message will not be read

I am willing to support here, but require some more details. Can you answer me my questions?

@EasyG0ing1, as you said in your email. JetBrains advised that they use libappindicator over D-Bus.

This looks like a pain to implement for Java. We'd have to do a few things.

1. Determine OS at runtime (Linux) as well as which Desktop Environment and version (GNOME, KDE, or a whole host of possible others).

afaik, should not be a big issues

2. Programatically install libappindicator support (assuming that a user doesn't have it already) or just assume that the library is already installed. Since FXTrayIcon is a library and not a bundled executable, I don't think we should do this, that can get messy quick.

we could try to find out if libappindicator is installed, if so use, else throw warning + link to how to install
So no need to make it more complex as it is

3. Register the icon via C/C++ (either JNI or JNA) keeping in mind that some of the FXTrayIcon features aren't supported by AppIndicator (tooltips, for example)

if we do not try, we will not see.
Have you got any reference code from IntelliJ, if so could you share?

4. Interface it all with Java to make it feel as smooth as development with Windows or MacOS is currently.

If this were a GUI with an executable, then this would be okay to do. We could have libappindicator as a dependency that gets resolved by APT or distribute as a snap package.

see above, linux users know how to install dependencies, if they get info WHAT to install.

As much as I would have liked to have it, I think I'm going to throw in the towel on supporting Linux. There's just too many hacks to be written due to the huge amount of choices/customizability that is offered.

Maybe, but here is someone who is willing to help ;-)

[EasyG0ing1]

@dpalic - I'll find the discussion I had with Jetbrains. If I remember correctly, they were very brief in their response, and no code examples were given that I can recall. That being said, we might be able to get them to put me in contact with one of the developers of their Toolbox application who might help further. They do seem to be a fairly accommodating company in general.

On the items you commented on:

Item 1 - I believe could be achieved with Apache Commons tools as they seem to have methods that provide this kind of granular information.

Item 2 - I believe this is how Jetbrains does it with their Toolbox application. As to whether or not this library should handle that for the user ... I see two schools of thought on that. First, a library is generally just a library and shouldn't be concerned with such matters, so throwing a message to the end user to install it should be sufficient. On the other hand, this library is all about the user interface, so would it really be out of character for it to install libappindicator, possibly even having it packaged in the library for installation so that it wouldn't be dependent on Internet connections, etc?

I know I've installed the Jetbrains Toolbox in multiple flavors of Linux, though I believe they all used Gnome, except for a version of Linux called Mint Cinnamon which doesn't use Gnome, but in that environment, the right-click feature of the tray icon doesn't seem to work.

I don't have any experience with the rest of what you listed here, but I'm also willing to do whatever I can to bring seamless Linux support to FXTrayIcon. It would be ideal to make the integration as seamless as possible for the end user, and I can't imagine that would be in any way invasive to the library as it is now. Even writing a separate class to handle the "Linux stuff" and then performing a test when the library is instantiated and if the environment is Linux, pass control over to that class.

[EasyG0ing1]

@dpalic So I tried to run a simple FXTrayIcon app on my MintCinamon Linux VM since it has Jetbrains Toolbox installed and working, the assumption being that the right components would be in place to where I could just get a tray icon without doing much else.

Here is the class that I ran

package com.simtechdata.linuxtrayicon;

import com.dustinredmond.fxtrayicon.FXTrayIcon;
import com.simtechdata.linuxtrayicon.ui.MainUI;
import javafx.application.Application;
import javafx.stage.Stage;

import java.io.File;


public class Main extends Application {
    @Override public void start(Stage primaryStage) throws Exception {
        String icon = "/home/michael/IdeaProjects/LinuxTrayIcon/src/main/resources/com/simtechdata/LinuxTrayIcon/L-Icon.png";
        File iconFile = new File(icon);
        if(!iconFile.exists()) {
            System.exit(0);
        }
        if(FXTrayIcon.isSupported()) {
            System.out.println("Tray Icon Supported");
            FXTrayIcon tray = new FXTrayIcon.Builder(primaryStage, iconFile)
                    .menuItem("Load Main",e->new MainUI())
                    .addExitMenuItem()
                    .build();
            System.out.println("Tray Icon Built");
            tray.show();
            System.out.println("Tray Icon is showing");
        }
        else {
            System.out.println("Tray Icon not supported");
        }
    }
};

And here is the output ... it never seems to instantiate FXTrayIcon and it throws no errors at all ... it just hangs.

Tray Icon Supported

[assada]

OS: Ubuntu 22.04
Kernel: 6.2.0
GNOME Shell 42.9
java 20.0.1

Toolbox, Zoom, Slack in tray.

But example above "just hangs" =(