Tray Icon bugged in linux

[xeruf]

[xeruf]

Seems to work now, apart from some weird white-ish around the icon 👍

[sghpjuikit]

I wonder what changed. Any change on your part? OS, OS update, anything?
The white bounds around the icon is due to lack of opacity support somewhere. Should not be happening. Definitely bug.

[xeruf]

uh you know what, it could somehow have been related to https://github.com/zulip/zulip-electron/issues/620

Have you not changed anything?

[sghpjuikit]

Perhaps.
Not that I know of.

The issue you describe is something I encountered on WIndows few times, but I do not remember how it got resolved. I think it has something to do with how TrayIcon.class handles the scaling and file support.

In any case we use awt/swing for tray so that should give you a hint about what we can expect. I tried to make it support hi-dpi to no avail. If you know of any way to use different solution I'm all ears.

I just realized that I never use tray for this application. Do you think Tray functionality is actually something this application needs? The Integrated search (CTRL+SHIFT+I) is much more convenient in my opinion.

[xeruf]

Tray is useful for when it is in background. You can do simple stuff like play/pause without calling the GUI. It could also have an only-tray mode which would drastically reduce background resource usage. So yes, definitely useful.
How does Integrated search relate to it though?

[sghpjuikit]

I get your point, but the actions user can invoke from try is limited (by design of it being a menu and by our choices of what we put in there). I doubt anyone will use pause/play from tray...

The search is relevant I think because it can do everything tray can do, faster, simpler and more convenient. It does not require application to be focused or 'open'.

Tray-only mode (I call it service mode) is already implemented, but it needs some more work. Use the search to find actions: Start app normally, Close app abnormally. In short application can be started with as single widget (name of which passed as argument), not restoring application state. The application state can be loaded anytime, manually, by user.

'True' service mode would mean that closing last window would not close the application. This is not supported at the moment, because there is no functionality that would leverage that. If you have any ideas Im all ears.

[xeruf]

I doubt anyone will use pause/play from tray

I already did. Why not?

In short application can be started with as single widget (name of which passed as argument), not restoring application state. The application state can be loaded anytime, manually, by user.

'True' service mode would mean that closing last window would not close the application. This is not supported at the moment, because there is no functionality that would leverage that.

What do you mean by not restoring application state? These two quotes seem contradicting to me.

[sghpjuikit]

If you are using it that's ok.

Responded to the latter on Zulip.