 further digging online, and StartupWMClass=Joplin and XDG_CURRENT_DESKTOP=Unity appear to be two known workarounds for the AppIndicator not working in Ubuntu.
If this is a bug, please use the template below. If this is a question, or a general discussion topic -...
Dropbox Seafile (on Ubuntu, Fedora disables libappindicator support via a compile time switch) Slack I think the problem is that many app developers don't...
Could the AppIndicator fix from the Snap be integrated into the official Joplin distribution?
Could the AppIndicator icon on Linux (or at least Ubuntu, idk about other distros) be changed to use the same resource as the Menu Bar icon on macOS?
This is a fairly minor thing, but the menu bar icon for Nextcloud is oversized and kind of pixelated on macOS...
It's been a while, but from what I remember adding the actual StartupWMClass line wasn't the magic fix for the snap. Joplin at the time was setting its X11 Class properly, the line was added for redundancy. The Unity 7 line was what made the initial progress there since it enabled Joplin to use the DBus approach Electron 7 used at the time to get app trays working.
Specifically, Joplin didn't use AppIndicator again until Joplin 1.4, I.E this commit for the snap Support libappindicator for system tray icons · MrCarroll/joplin-snap@2b7c238 · GitHub. It probably was used in the past, but it certainly wasn't using it for a significant portion of 2020 (I imagine Laurent knows when Joplin originally transitioned to Electron 7).
I can take a look and see if I can improve the AppIndicator icon itself, I imagine it's just using the same icon as in the AppDrawer, there might be a way to adjust it on my end.
Thanks! I actually linked to the function in ElectronAppWrapper.ts that seems to be responsible for the AppIndicator icon being different from the macOS one.
Line 270 could be replaced with...
...for Joplin to use the macOS icon on Linux. That said, some Linux distros seemingly prefer high-resolution color AppIndicator icons, but Electron is hardcoded to resize any larger icon down to 22px. That said, the icon would probably be slightly sharper if the image was 22x22 rather than 16x16. And I don't know how macOS does scaling for Menu Bar icons, but it presumably scales down from a higher resolution. So it might be better to specify separate "tray" icons for Linux and macOS.
I forced the MacOS icon on Ubuntu 20.04, it ends up looking like this.
I agree that the default icon ends up looking out of place, but the MacOS icon ends up lacking so much contrast with the theme it could end up being invisible on certain monitors, maybe other environments would fare better such as by having a transparent task bar like the MacOS screenshot, but as is with Ubuntu being the biggest distribution and thus default, there'd probably need to be another icon instead.
IMHO the double-line edge around the macOS notification-area icon looks a bit busy at that scale and could probably be simplified. I'm not sure what the norm is on Linux, but two of the AppIndicator icons I have are circular, so that might look better. I can try creating an alternate version myself, but I probably won't get around to it today because I have a nasty cold.
You could also just try rendering JoplinIconBlack.svg at 22px, since apparently that's the fixed size of AppIndicator icons for Electron.
I should probably try and figure out setting up a Joplin dev environment on Ubuntu, since at the moment I just have one set up on macOS.
IMHO the roundrect is probably the most legible at the size AppIndicators use on Ubuntu.
I can try and set up a Joplin development environment on my Ubuntu box so that I can test this myself.
Because the tray icon for dev builds is also gray, my thought was that there could be a different colorway for these icons in, say, traffic-cone orange for that purpose. I can try and build Joplin on my Mac to see how these same PNGs (in black) look. And if you have a working Windows setup, you could check to see how these three tray icons look on there, too, and what color might work best as a default.
I think it's important to say that I'm not part of the official Joplin development team, I do have that snap and it has plenty of users, but otherwise I've the same influence as anybody else when it comes to design choices like this.
That said I like it. I've tried it locally and personally I think the rounded rectangle looks the best, particularly the first iteration without the tint. I can't exactly the describe it, the tinted versions on Ubuntu's defaults seemed to have better contrast, so identifying the J was easier, but the non-tinted versions just seemed to stand out more. On the technical side, I'm limited with what I can do with the snaps due to their sandboxing, I wouldn't even be sure if telling if the system was in dark mode would actually work reliably from system to system, so I'd veer on the preference of using the version that wasn't so specically targetted to a single systems default.
I haven't messed with themes on Linux myself in years. So I just installed KDE on Ubuntu instead, where the difference between the tinted circle and the untinted rectangle look like this.
I don't personally publish any dev builds of Joplin so I've no real input to offer on the dev builds icons.
And unfortunately I don't have a proper Windows testing environment so I can't be particularly helpful there, sorry.
However, as far as the snap itself goes, I'd personally be willing to use these icons if you'd allow it. In the specific context of Linux which is all I have to worry about, these match the general system theme much better and I doubt the core devs would have an issue with it. However I think it's probably worth trying to get their attention, because I reckon they'd be adopted upstream anyway!
Regarding the tint, I went in with the eyedropper tool in your screenshots, and the other KDE tray icons are 94%-luminance gray. So they're not 100% white, either, but they're a slightly different tint. Electron not supporting SVG indicator icons seems to be an upstream problem with Chromium, so I was thinking of creating an issue on the chromium.org issue tracker. (EDIT: see here.) I would not be surprised if a proper SVG indicator icon ended up using the correct fill color on both GNOME Ubuntu and KDE.
On my open pull requests for the application icons, @laurent mentioned the lack of engagement here on the forum as a reason to hold off on approving them, so soliciting feedback from other users like you is an important part of the process (and indeed you can update GitHub pull requests with additional commits).
My thought for once I do a pull request for the tray icons in the main repository is that I will include the SVG for all three shapes but only use the plain square one in the build for the time being. The book icon I did in part because I made some book icons in the other thread, as well.
It turns out that, unlike on Linux, where Electron scales AppIndicator icons to a fixed size, on macOS Electron leaves them pixel-perfect, with the only option being 2x pixel density. The icons would probably also look slightly sharper if the vector drawing fit more closely to the pixel grid, though this is mostly noticeable with the book and with the "J" glyph.
In each of the images, the icon is 28px x 28px, but this could be changed if a slightly different size looked better. Note that the Emoji Palette icon to the right of the Joplin icon is 30px x 24px, and the Time Machine icon to the right of that is 32px x 26px.We provide a general lower bound on the dynamics of one dimensional Schrödinger operators in terms of transfer matrices. In particular it yields a non trivial lower bound on the transport exponents as soon as the norm of transfer matrices does not grow faster than polynomially on a set of energies of full Lebesgue measure, and regardless of the nature of the spectrum. Applications to Hamiltonians with a) sparse, b) quasi-periodic, c) random decaying potential are provided. We also develop some general analysis of wave- packets that enables one to characterize transports exponents at low and large moments.
Nous fournissons une borne inférieure générale pour la dynamique des opérateurs de Schrödinger unidimensionnels en fonction des matrices de transfert. En particulier, cela donne une borne inférieure non triviale pour les exposants de transport dès que la norme des matrices de transfert ne croît pas plus vite que polynômialement sur un ensemble d'énergie de mesure de Lebesgue pleine, et ce indépendamment de la nature du spectre. Des applications avec des hamiltoniens avec des potentiels a) épars, b) quasi-périodique, c) aléatoires décroissant sont données. De plus, nous développons dans un contexte général une analyse des paquets d'