Evaluate whether migration from lynxtray(infi.systray) to pytray makes sense

[C0rn3j]

infi.systray is dead, we were using it for Windows systray.

I have forked it as lynxtray and fixed the glaring issues that were spamming the log, and we now use that.

There is however pystray, which is cross-platform for macOS/Windows/Linux(X only??) - https://github.com/moses-palmer/pystray - it looks similarly dead, but it may make sense to switch to fork it and switch to it.

If we stay with the infi.systray fork, it makes sense to go through https://github.com/Infinidat/infi.systray/pulls and issues and take what's useful.

[Taiko2k]

lynxtray would be easier since its already implemented.

My feeling is to avoid a cross platform lib on Linux as Linux support is intended to be first class. (i.e if there's any potential sacrifice to feature support then I'd rather not use a cross-platform lib there)

[Solarunit]

My feeling is to avoid a cross platform lib on Linux as Linux support is intended to be first class. (i.e if there's any potential sacrifice to feature support then I'd rather not use a cross-platform lib there)

Thanks for the first class Linux support! ❤️ 🐧 🎧

[C0rn3j]

My feeling is to avoid a cross platform lib on Linux as Linux support is intended to be first class.

We can use the lib only on Windows (and possibly macOS) if necessary.

pystray does not seem to have support for the dbus-based SNI anyway, so we would not be fixing much with it on the Linux side, as #1316 would still need to be resolved.

The question is if pystray has better functionality for Windows over the now-forked lynxtray

[C0rn3j]

Gonna close this, can be revisited later if needed, seems to work for now.