I gather that if the panel crashes (unlikely, but possible), all processes that are tray-icon-only will be killed and will not restart when the panel is restarted. Such a situation would be avoided.

This doesn't happen . Panel can be stopped and restarted without consequences for tray apps.

Tray apps aren't affected by the absence of the tray.

This is necessary since the panel is a heavy software, and may take longer to start compared to lighter apps like featherpad.

The delay isn't only for lxqt-panel — the user may prefer another panel under LXQt (LXQt is modular) — but for any tray, that may be provided by any app/panel.

Actually, in all setups that I've had, lxqt-panel has provided the tray in the shortest possible time (you should try KDE Plasma to see that). I don't think a separate daemon would solve anything.

If there's a problem under Wayland, it should have another cause, which should be found and fixed.

Split the Status Notifier Watcher (code that implements org.kde.StatusNotifierWatcher) and make it a simple daemon.

What would such daemon do?
Would it be GUI-less?

• no -> Would it copy/re-implement all the necessary lxqt-panel logic to position/show the tray icons, menus, etc.?
• yes -> How would the tray icons/menus be shown? Would it just be a "bridge" between the client applications and the GUI application (lxqt-panel)? How would these two interact (new API specification?)?

This doesn't happen . Panel can be stopped and restarted without consequences for tray apps.

@stefonarch I said that from my experience with lxqt-panel (0.16.1, Debian Stable), used outside lxqt-session with custom window manager I was working on. I am sure this has already been fixed in the latest release, and will take your word for it.

yes -> How would the tray icons/menus be shown? Would it just be a "bridge" between the client applications and the GUI application (lxqt-panel)? How would these two interact (new API specification?)?

@palinek Yes. The daemon I proposed would be a gui-less daemon. It is intended to be a bridge between client applications and the GUI - lxqt-panel or any other lxqt-based GUI that may be developed eventually.

Currently, you use the following code:

connect(mWatcher, &StatusNotifierWatcher::StatusNotifierItemRegistered, this, &StatusNotifierWidget::itemAdded);
connect(mWatcher, &StatusNotifierWatcher::StatusNotifierItemUnregistered, this, &StatusNotifierWidget::itemRemoved);

All that needs to be done is switch to the dbus version of the signals:

QDBusConnection::sessionBus().connect(
        WATCHER_SERVICE, WATCHER_OBJECT, WATCHER_PATH, 
        "StatusNotifierItemRegistered", "s", this, SLOT( itemAdded( QString ) ) 
);

Everything else remains the same.