libappindicator support#2862
Conversation
Change icon depending on any vault unlocked Delete unneeded icon
|
Depends on cryptomator/integrations-api#17 |
|
Incredible contribution! 🚀 Even though I'm not qualified to give much feedback regarding Linux systems, I just wanted to let you know that we already have a monochrome icon (e.g., we're using it for the menu bar icon on macOS). I've sent the SVG file via Slack, maybe you can use that (and fix anything in the SVG if necessary)? |
|
@purejava Cool! However, this is the wrong place. Since this is Linux specifc, the implementation needs to be placed in https://github.com/cryptomator/integrations-linux. Create a new package like for other implemented interfaces (as can be seen in https://github.com/cryptomator/integrations-win/tree/develop/src/main/java/org/cryptomator/windows) and after the implementation is done, create a service provider entry. Regarding the selection of the service implementation: This can be controlled by the |
overheadhunter
left a comment
There was a problem hiding this comment.
While I agree this needs to be done in integrations-linux, I want to leave some general remarks already.
| requires com.tobiasdiez.easybind; | ||
| requires dagger; | ||
| requires io.github.coffeelibs.tinyoauth2client; | ||
| requires libappindicator.gtk3.minimal.java; |
There was a problem hiding this comment.
I would strongly suggest to align the module name with the package name and make sure that both follow reverse domain name notation for a domain that you control. Otherwise we might have to deal with split packages again.
|
|
||
| @CheckAvailability | ||
| public static boolean isAvailable() { | ||
| return SystemUtils.IS_OS_LINUX && MemoryAllocator.isLoadedNativeLib() && SystemTray.isSupported(); |
There was a problem hiding this comment.
SystemTray.isSupported() should not be needed, since this only determines whether the AWT system tray is supported, which might not be the case while libappindicator is still available.
| <slf4j.version>2.0.6</slf4j.version> | ||
| <tinyoauth2.version>0.5.1</tinyoauth2.version> | ||
| <zxcvbn.version>1.7.0</zxcvbn.version> | ||
| <appindicator.version>1.0.0-SNAPSHOT</appindicator.version> |
There was a problem hiding this comment.
This requires JDK 19 (not >= 19 but == 19), which is fine atm but we're in the process of switching to JDK 20 which will break support, as this is compiled with --enable-preview.
Not really a problem right now, but as long as Panama is a preview feature, this might force us to temporarily drop support for this tray icon implementation again, when updating the JDK.
I would suggest that you use JDK 20 already, since it is only a matter of days - weeks for us to make the switch.
|
Thanks for the quick and thorough feedback @tobihagemann, @infeo and @overheadhunter! I'll change the package names and the other recommendations as well and will move the stuff to |
@infeo I thought about this. In principle, I am used to the integrations concept from writing keychain implementations. The So what should be placed in integrations-linux from your point of view? What sort of provider and which methods should it provide? |
|
To cite the doc of the
For an example, see https://github.com/cryptomator/integrations-mac/blob/develop/src/main/java/org/cryptomator/macos/tray/MacTrayIntegrationProvider.java. When you do not need this interface, you can ignore it. From my point of view, it has a bad naming. The package contains two different services. We should rework the name scheme. tl;dr: Just use the |
This PR changes the tray icon support for Linux away from AWT towards the libappindicator library as suggested in #1645.
It displays SVG versions of the Cryptomator icon, that scale and should look ok on all desktop environments. On GNOME 43 and KDE 5.24.7 they look like this:
Some notes on requirements to use libappindicator:
libappindicator3-1, on Arch linux it's calledlibappindicator-gtk3Some notes from the development perspective:
resourcesdirectly (not in theimgfolder like the other files) as their full path needs to be determinedintegrations-apiwas capable of handling PNG files (as byte[] streams), but needed to be widened to handle SVG as well