Fix server GUI not exiting on KDE (#3016)

[mcfnord]

Note

📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.

Fixes #3016.

On some desktop environments — reported on KDE with Qt 5.15 (Ubuntu 22.04+, Fedora 37+) — closing the server GUI (X button, Window → Exit, Ctrl+Q, or the tray Exit entry) only hides the window. The process and the system tray icon keep running, and the only way out is killall. On Windows the same actions terminate the process as expected.

This applies the pragmatic fix that project member @dingodoppelt reported as working in the issue thread: explicitly call QApplication::quit() at the end of CServerDlg::closeEvent, after the geometry is saved and the event is accepted.

void CServerDlg::closeEvent ( QCloseEvent* Event )
{
    // store window positions
    pSettings->vecWindowPosMain = saveGeometry();

    // default implementation of this event handler routine
    Event->accept();

    // ... KDE workaround ...
    QApplication::quit();
}

Scope: one added call plus the #include <QApplication> it needs — server dialog only, exit path only. Nothing on the client, the audio path, or any running-state behaviour is touched.

This is deliberately the pragmatic fix, not the dignified one. As @dingodoppelt noted, QApplication::quit() here is a workaround, not the clean design — the underlying cause looks like threads not being torn down in time, and the proper solution is likely a signals/slots-based shutdown (the discussion in #3372 / #3402 / #3654 is the right home for that). The trade-off this PR offers is: KDE users get a server that actually exits today, at the cost of a line everyone agrees is a placeholder.

So — if you would rather hold out for the real, official, proper shutdown refactor, please just close this PR. No offence taken. It is here purely so the option of shipping the known-working one-liner now is on the table, in case that is preferable to leaving a three-year-old "the app won't quit" bug open while the larger design is worked out.

Testing note, stated plainly: the change compiles cleanly on desktop Linux (Qt 5). I have not reproduced the original KDE hang on my own setup, so I cannot personally confirm the fix on affected hardware — its credibility rests on @dingodoppelt having tested exactly this call and reported it resolved the problem. A confirmation from anyone who can reproduce the original bug would be welcome before merge.

[dingodoppelt]

I'd rather not do the quick and dirty fix since we have an underlying issue which is maybe even entangled with other issues we see.
As with the reverb: we might just get rid of the tray icon altogether. I wonder why we don't have a tray icon for the client, where it would make much more sense.

[ann0see]

What would a tray icon for the client really gain? For the server it definitely makes sense to have an easy GUI way to interact with a backgrounded process.

[dingodoppelt]

What would a tray icon for the client really gain? For the server it definitely makes sense to have an easy GUI way to interact with a backgrounded process.

In practice the client is backgrounded for many users because the screen is used up by either sheet music or a video chat app. Some even need to walk away from their computers to be able to play their instruments (Drummers, Pianists, Double Bass players, ...)
I'd say a tray icon indicating the mute status via colour and containing some shortcuts like favourite servers or the connect dialogue (or maybe a configurable set of shortcuts?)
Ideally a user forgets about Jamulus while playing and a GUI only gets in the way once you are connected.