Show icons for flatpacked app

[purejava]

This handles the different Linux flavors of Cryptomator.

There is no way to set an icon theme with app_indicator_new_with_path for a flatpacked app. This is the reason for this code change.

[infeo]

Can you point me to the libappindicator api documentation?

Because, instead of using a property set downstream, we could first try app_indicator_new_with_path(...) and just fallback to app_indicator_new(...) in the error case. But that is only possible if there is some sort of error handling.

[purejava]

Can you point me to the libappindicator api documentation?

Because, instead of using a property set downstream, we could first try app_indicator_new_with_path(...) and just fallback to app_indicator_new(...) in the error case. But that is only possible if there is some sort of error handling.

I couldn't find any api documentation, only the code of the libs:
https://bazaar.launchpad.net/~indicator-applet-developers/libappindicator/trunk/view/head:/src/app-indicator.c
https://github.com/AyatanaIndicators/libayatana-appindicator/blob/master/src/app-indicator.c

[purejava]

The last two commits 6b482da and 36b1ee4 reduce the log messages of the bindings to info (keep out the stack trace), in case a native library could not be loaded and enable saving vault passwords in kdewallets.

[infeo]

I have a new idea/approach for the "if flatpak, then this, else check APPDIR"-thing. Let's introduce a new JVM property and document this property in the README (like done in https://github.com/cryptomator/integrations-win#config):

• org.cryptomator.integrationsLinux.appIndicator.svgSource - specifies the path from which the svg images are loaded

If the property is not specified (== null), the flatpak approach via app_indicator_new(...) is used. If the property is specified, we are using its value without validation in the app_indicator_new_with_path(...) function.

Then the downstream library consumer can control, where it is loaded from and in the starting script/ build process we can define it appropiately for the target distribution.

I would also split the KDE-Wallet changes into a seperate PR. (or for sake of brevity i'll cherry pick'em).

[purejava]

I have a new idea/approach for the "if flatpak, then this, else check APPDIR"-thing. Let's introduce a new JVM property and document this property in the README (like done in https://github.com/cryptomator/integrations-win#config):

* `org.cryptomator.integrationsLinux.appIndicator.svgSource` - specifies the path from which the svg images are loaded

If the property is not specified (== null), the flatpak approach via app_indicator_new(...) is used. If the property is specified, we are using its value without validation in the app_indicator_new_with_path(...) function.

Then the downstream library consumer can control, where it is loaded from and in the starting script/ build process we can define it appropiately for the target distribution.

I would also split the KDE-Wallet changes into a seperate PR. (or for sake of brevity i'll cherry pick'em).

Thanks for that good suggestion @infeo. Please note, that for the AppImage it will still be necessary to evaluate System.getenv("APPDIR"), as we need to now, where the AppImage was mounted, because this determines where to find the icon theme. The last parameter of app_indicator_new_with_path is the icon theme path.

So in the end, the code will look pretty much the same. I'll go on and implement your suggestion!

[infeo]

Please note, that for the AppImage it will still be necessary to evaluate System.getenv("APPDIR"), as we need to now, where the AppImage was mounted, because this determines where to find the icon theme.

Yes, but we can't we evaluate it in the AppImage start script?

[purejava]

Yes, but we can't we evaluate it in the AppImage start script?

Sure. The JVM property would be set in the script/ build process, modified in the AppImage start script and used in the AppindicatorTrayMenuController. I'll do it that way.

[purejava]

Yes, but we can't we evaluate it in the AppImage start script?

I am afraid this is not possible. Java system properties are only accessible by the process they are added to.

Edit: @infeo so the two commits above implement it as far as possible. The code is tested and working for the AppImage. If you could provide a new deb in the ppa, I would test that too.

[infeo]

So, i talked with @overheadhunter about this matter and he mentioned an interesting preview feature of JDK 21: String templates. We already thought about changing JVM properties at runtime to adjust to different system envs and have a plan now (will link it later edit: see cryptomator/cryptomator#2957). With string templates we can do it in a regulated way and already using a new JDK feature.

@purejava What does this mean for this PR? Drop evaluation of APPDIR and only use the JVM property, like I initially proposed. I'll make changes in Cryptomator such that the property will have the correct value when calling showTrayIconWithSVG()

[purejava]

So, i talked with @overheadhunter about this matter and he mentioned an interesting preview feature of JDK 21: String templates. We already thought about changing JVM properties at runtime to adjust to different system envs and have a plan now (will link it later). With string templates we can do it in a regulated way and already using a new JDK feature.

@purejava What does this mean for this PR? Drop evaluation of APPDIR and only use the JVM property, like I initially proposed. I'll make changes in Cryptomator such that the property will have the correct value when calling showTrayIconWithSVG()

Thanks for the innovative suggestion! Changes are done. Please note my comment above, regarding kdewallet.

[infeo]

The last request for change, i promise! 😇