First I don't really like the fact that the status tray icon is only displayed if hide on close is enabled. It should rather be enabled at all times.
Status display works fine although I don't like the visual appeal as you have to know what is is displaying. (But is ok for now)
Whats not ok is the unread messages displaying! First the little square where it is displayed at the moment is way to small as it just cuts of half of the number on Linux Arch and doesn't even display anything on Microsoft Windows.
I suggest displaying the unread messages amount when the status tray icon is clicked just like the operations you can perform.
Additionally I noticed a severe bug: if you have unread messages and close the clien't down, the next time you open it again you have the double amount of unread messeges displayed as the client received them twice each. (The number in the status tray icon is more or less comlpetely random after the second start it seems). Please investigate on this!
@DieGurke the issue on Arch Linux arises from the fact that KDE's status tray API has evolved from what AWT's StatusTray has been designed for (Java 5).
The StatusTrayIcon runs using a legacy API which doesn't seem to handle scaling the same way Eclipse or the rest of Envoy does.
Apart from writing platform-specific C code using JNI / JNA, we cannot do much about this, however @delvh pointed out to me that DPI scaling can actually work without the explicit setting of environment variables.
I will look into the issue you describe for Microsoft Windows, however.
@DieGurke@kske I guess I know where this bug is originating from: IIRC, loadUserData gets called twice when using token authentication. Each time, the chats get reloaded. And as the totalUnreadAmount always gets updated when readObject gets called, it'll show twice the amount of messages. That is my semi-educated guess.
First I don’t really like the fact that the status tray icon is only displayed if hide on close is enabled. It should rather be enabled at all times.
@DieGurke as long as the default value stays false, I have nothing against it.