Complete rewrite of the tray icon implementation

[Hartmnt]

FEAT(client): Fully rewrite tray icon implementation

The old tray icon implementation was very old and contained a lot of workaround for things that probably are no longer an issue.
Furthermore, the event loop was modified in a way such that it could end up in an infinite loop draining CPU time and rendering Mumble unusable.

Based on the new Qt5 implementation, this commit introduces a complete rewrite of the tray icon. The following things should be noted:

• We assume the information in the Qt documentation [1] is valid. This means that all versions of Windows, all Linux window managers/compositors that implement the d-bus StatusNotifierItem specification, and all versions of macos support the functionality of QSystemTrayIcon and its notification system. That means we can drop the platform-specific code branches and handle messages directly with QSystemTrayIcon::sendMessage. This should for example also be true for recent versions of Gnome, which do not have an actual system tray, but implement the d-bus StatusNotifierItem specification. Therefore, we can actually merge and simplify the notification code for Windows and Unix*.

• With regards to the bullet point above, we only limit the "hide to tray" functionality behind QSystemTrayIcon::isSystemTrayAvailable (because otherwise you would not get the Mumble window back without binding a shortcut first). Other code branches that were previously limited when isSystemTrayAvailable
  returned false were removed. According to Qt, the QSystemTrayIcon code does not actually care if a system tray is available and will even retroactively add itself if a tray becomes available after the application was started.

• On (X)Wayland, the minimize button in the window frame does not trigger a minimize change event. This means that users with such a system may only be able to "hide to tray" by 1) pressing the close button in the window frame and enabling "minimize instead of close" 2) clicking the tray icon or the tray icon hide action or 3) binding a shortcut to hide the window. This is either a bug or a deliberate decision by Qt or Wayland and we have no way to do anything
  about that. (QTBUG-74310)

• The "messageClicked" event is buggy in Qt on some platforms. That means that clicking the system notification spawned by Mumble via QSystemTrayIcon::sendMessage will (on some systems) never trigger anything especially not showing and activating the window. This is a long-standing bug in Qt (QTBUG-87329), but we have absolutely no way to work around this. The event is correctly hooked up in Mumble and if this is ever fixed in Qt, this will start working again automatically.

• The tray icon has been redesigned according to state-of-the-art tray icon design guidelines [2]. Which basically just means: 1) d9a2d47 has been reverted to provide the user with a consistent menu 2) The main action of the tray icon (toggle show/hide) is the first entry in the context menu and the default action when the icon is clicked and 3) the TalkingUI toggle action was added. Actions for double and middle mouse clicks were removed as they might have contributed to infinite loops.

• There is no way in Windows to show and activate a window that is not part of the current active process. If you have Mumble running in the background and receive a message, we can not raise the Window without
  you clicking the Mumble taskbar item or tray icon yourself. This is deliberate by Microsoft and can and should not be circumvented. (Main window doesn't receive focus when Mumble-specific Windows notification is clicked #5701)

• This also fixes the case where the Mumble MainWindow would disappear when pressing "OK" in the settings dialog. This happened because users would have "minimize to tray" and "minimize on close" enabled.

[1]
https://doc.qt.io/qt-5/qsystemtrayicon.html#details
https://doc.qt.io/qt-6/qsystemtrayicon.html#details

[2] https://learn.microsoft.com/en-us/windows/win32/uxguide/winenv-notification

FEAT(client): Implement tray icon highlighting

Previously, only "window highlighting" was supported by Mumble. However, when Mumble was minimized to tray,
there was no way to observe that highlighting.

As requested in #4584, this commit introduces highlighting to the tray icon. When a highlight message is received, the
tray icon will flash the "information icon" every two seconds until the MainWindow of Mumble receives focus again.

To enable this for a specific message type, the user needs to check the "highlight" box in the "Messages" configuration dialog.

FEAT(client): Add --hidden cli option to start Mumble hidden in tray

This commit introduces the "--hidden" cli option which prevents Mumble and the ConnectDialog to show up on startup.
This is especially useful for users who want to automate the startup process without human interaction.

Testing:

	Linux (X11 with XFCE)	Linux (XWayland KDE)	Windows	MacOS
Able to receive desktop notifications?	👍	👍	👍	👍
With minimize to tray enabled, does clicking the tray icon and/or clicking the first action of the context menu of the tray icon hide and show Mumble correctly?	👍	👍	👍	😐 (Left click opens context menu. Minimize instead of hide)
With minimize to tray and "ask on quit" dialog disabled, does pressing the close button in the title bar hide Mumble correctly?	👍	👍	👍	😐 (Minimize instead of hide)
With minimize to tray and "ask on quit" dialog enabled, does pressing the minimize button in the dialog hide Mumble correctly?	👍	👍	👍	❌ (Minimize only)
With minimize to tray enabled, does pressing the minimize button in the title bar hide Mumble correctly?	👍	❌	👍	❌ (Minimize only)
Is a maximized Mumble MainWindow still hiding and restoring correctly?	👍	👍	👍	😐 (Minimize instead of hide)
In Settings -> User Interface, is there a settings group box called "Tray Icon"?	👍	👍	👍	👍
Does pressing "OK" in the settings dialog not hide Mumble?	👍	👍	👍	👍
Receive a message for which "highlight" is enabled. Does the tray icon blink using the "i"-icon every two seconds until the MainWindow receives focus?	👍	👍	👍	👍
Does clicking a desktop notification restore and focus Mumble?	❌	❌	❌	👍
Does starting Mumble with --hidden actually work?	👍	👍	👍	❌ (Explicitly disabled on macOS)

[Krzmbrzl]

(Potentially) relevant issues:

• Clicking the voice activity tray icon causes mumble to use 100% cpu #3977
• Improve handling of mumble + system tray #3879
• Show number of participants in currently joined channel in tray icon #5261
• client: change tray icon in hidden state #4584
• Tray icon menu appears way above tray icon #3999
• Differentiate icons for improved skinning #1574

[Hartmnt]

@Krzmbrzl I considered #5261 but you can not really add text to the tray icon. So you would have to use the themed status icon you want to display and - at runtime - add some numbers to it, which seems... cumbersome... The other issues except #1574 are already referenced in the commit messages

[Krzmbrzl]

I just wanted these references to appear here in the GitHub UI explicitly to make sure everything is linked together correctly.

[Snowknight26]

With https://dev.azure.com/Mumble-VoIP/Mumble/_build/results?buildId=8469&view=results, on Windows 10:

Able to receive desktop notifications?

• Yes

With minimize to tray enabled, does clicking the tray icon and/or clicking the first action of the context menu of the tray icon hide and show Mumble correctly?

• Yes

With minimize to tray and "ask on quit" dialog disabled, does pressing the close button in the title bar hide Mumble correctly?

• Yes

With minimize to tray and "ask on quit" dialog enabled, does pressing the minimize button in the dialog hide Mumble correctly?

• Yes

With minimize to tray enabled, does pressing the minimize button in the title bar hide Mumble correctly?

• Yes

Is a maximized Mumble MainWindow still hiding and restoring correctly?

• Yes

In Settings -> User Interface, is there a settings group box called "Tray"?

• Yes ("Tray Icon")

Does pressing "OK" in the settings dialog not hide Mumble?

• Yes

Receive a message for which "highlight" is enabled. Does the tray icon blink using the "i"-icon every two seconds until the MainWindow receives focus?

• Not sure what "highlight" is enabled means in this context

Does clicking a desktop notification restore and focus Mumble?

• Restore? Yes. Focus? No, taskbar icon keeps blinking but the Mumble window doesn't always become the the foreground one. In Main window doesn't receive focus when Mumble-specific Windows notification is clicked #5701 you wrote "Which means that I believe that Mumble should at least be correctly restored from minimization now", though this PR doesn't seem to make any changes to this.

Does starting Mumble with --hidden actually work?

• Yes
• Interestingly, having Mumble already started and then running mumble.exe --hidden again causes Mumble to appear in the task bar, blinking, but Mumble's main window does not appear. (Same behavior as 1.5.634 running mumble.exe again.) Starting Mumble for the first time using this command line argument, however seems to prevent Settings -> Network -> Reconnect to last server on startup from working.

[Hartmnt]

• Not sure what "highlight" is enabled means in this context

There is a checkbox for "highlight" in the Settings -> Messages table view. If enabled, it should highlight the application in the task bar (some sort of blinking iirc) and as of this PR also change the tray icon. The effect should only apply, if Mumble has no focus and only lasts until the Window receives focus again.

• though this PR doesn't seem to make any changes to this.

It does:

mumble/src/mumble/MainWindow.cpp

Lines 3631 to 3638 in e0cd306

	qDebug() << "Tray: Show raise window requested!";
	setWindowState(windowState() & ~Qt::WindowMinimized);
	QTimer::singleShot(0, [this]() {
	show();
	raise();
	activateWindow();
	setWindowState(windowState() | Qt::WindowActive);
	});

It first restores the window from minimization and adds a timer to the raise and activate of the window.

• Settings -> Network -> Reconnect to last server on startup

Good catch, I think this is a regression I should try to fix.

[Snowknight26]

There is a checkbox for "highlight" in the Settings -> Messages table view.

That's what I was missing, thanks! Highlighting works as expected.

Unrelated to this PR but the first column of that table has some usability issues as the text is cut off, at least in Windows, making it hard to know what you're enabling highlighting (or any other option) for.

• though this PR doesn't seem to make any changes to this.

It does:

mumble/src/mumble/MainWindow.cpp

Lines 3631 to 3638 in e0cd306

	qDebug() << "Tray: Show raise window requested!";
	setWindowState(windowState() & ~Qt::WindowMinimized);
	QTimer::singleShot(0, [this]() {
	show();
	raise();
	activateWindow();
	setWindowState(windowState() | Qt::WindowActive);
	});

It first restores the window from minimization and adds a timer to the raise and activate of the window.

Ahh sorry, what I meant was that during testing, I couldn't find any discernable difference in functionality between this version and 1.5.634.

[Hartmnt]

That's what I was missing, thanks! Highlighting works as expected.

Nice.

Ahh sorry, what I meant was that during testing, I couldn't find any discernable difference in functionality between this version and 1.5.634.

Ah ok. Well as stated in your original issue, it is sadly not possible for us to arbitrarily focus the Mumble MainWindow. But it is good to know that de-minimization works as expected.

[Krzmbrzl]

I still struggle to visualize how you want this to be done.

Never call any tray icon functions from the outside (unless you are certain that the call happens in the same thread hat the tray icon lives in). Instead, emit a signal that is wired up to the respective slot of the tray icon. That solves all potential issues with regards to concurrency (since by default Qt never uses direct connections) thanks to how Qt handles signals and slots.
Having the tray icon be event driven instead of directly driven (via explicit calls) is probably also a tad cleaner in terms of general implementation 🤔

[Hartmnt]

@Krzmbrzl Kindly check out the last experimental commit :) Is this what you had in mind? I guess it just feels weird to me because the signals are not emitted by the TrayIcon class, but all the calls now go through the signal slot mechanism, right?

[Krzmbrzl]

Is this what you had in mind? I guess it just feels weird to me because the signals are not emitted by the TrayIcon class, but all the calls now go through the signal slot mechanism, right?

Not quite - what you want here is to make e.g. the MainWindow have (new) signals that it emits. These are then wired up to the tray icon's slots. That makes things conventional again (signals of a class are only emitted by that class itself in reaction to an observed change).

all the calls now go through the signal slot mechanism, right?

I guess - I'm not sure how Qt handles class-external parts emitting a class's signals 😅

[Hartmnt]

the MainWindow have (new) signals that it emits

Ah. Ok. Well, that would work. I am just not sure, if that would make sense from a structural perspective. Because that would mean we would have tray icon specific signals in the MainWindow class just for that purpose?

I guess - I'm not sure how Qt handles class-external parts emitting a class's signals

Should make no difference as emit itself is a no-op.

[Krzmbrzl]

Ah. Ok. Well, that would work. I am just not sure, if that would make sense from a structural perspective. Because that would mean we would have tray icon specific signals in the MainWindow class just for that purpose?

Just don't frame them as tray-icon specific. The tray icon reacts to certain events. Make these events signals (with a name that only reflects the event, not something like makeTrayIconDoX). That should be possible, shouldn't it?

Should make no difference as emit itself is a no-op.

Yes, but Qt does some magic on its own when handling signals and slots (e.g. in order to implement the thread safety features)

[Hartmnt]

Just don't frame them as tray-icon specific. The tray icon reacts to certain events. Make these events signals (with a name that only reflects the event, not something like makeTrayIconDoX). That should be possible, shouldn't it?

I see. Yes, I guess that would work! Check out the latest changes to the experimental commit.

[Krzmbrzl]

Yes, that's what I had in mind 👍

[Hartmnt]

@Krzmbrzl Anything left to do here? :)