Some Qt apps use the legacy tray icon if launched before the extension is enabled about gnome-shell-extension-appindicator

[3v1n0]

Likely a duplicate of #516 at least in its manifestation, can you confirm?

[theofficialgman]

I checked, implementing #516 does nothing to fix this issue.

One thing I will note is on Jammy the barrier menu can be opened with a single left click. A single left click on Noble does nothing at all for barrier. A right click pops the menu up on the left like shown above.

A double click on both jammy and noble opens the application itself.

[3v1n0]

What you see is the legacy menu that an indicator may show when double-clicked, once that would help.

[3v1n0]

I've tested this in noble with barrier but I couldn't reproduce, can you please provide more steps?

[theofficialgman]

It seems to be dependent on the spawn order of the extension indicators. If I start barrier by manually launching barrier after boot then it works. If I have barrier autostart on login (use gnome startup application) then I have the issue.

[3v1n0]

So, I've checked this again and indeed you're right in fact it's enough to run the shell in an X11 session with this hack:

diff --git a/statusNotifierWatcher.js b/statusNotifierWatcher.js
index 915c860..8fa50c8 100644
--- a/statusNotifierWatcher.js
+++ b/statusNotifierWatcher.js
@@ -23,6 +23,7 @@ import * as Interfaces from './interfaces.js';
 import * as PromiseUtils from './promiseUtils.js';
 import * as Util from './util.js';
 import * as DBusMenu from './dbusMenu.js';
+import * as ShellUtil from 'resource:///org/gnome/shell/misc/util.js';
 
 import {DBusProxy} from './dbusProxy.js';
 
@@ -41,6 +42,15 @@ const DEFAULT_ITEM_OBJECT_PATH = '/StatusNotifierItem';
 export class StatusNotifierWatcher {
     constructor(watchDog) {
         this._watchDog = watchDog;
+        this._initAsync().catch(logError);
+    }
+
+    async _initAsync() {
+        ShellUtil.spawn(['barrier']); // or clementine or any Qt app
+        await new PromiseUtils.TimeoutSecondsPromise(
+            2, GLib.PRIORITY_DEFAULT, null);
+        print('wait done');
+
         this._dbusImpl = Gio.DBusExportedObject.wrapJSObject(Interfaces.StatusNotifierWatcher, this);
         try {
             this._dbusImpl.export(Gio.DBus.session, WATCHER_OBJECT);

HOWEVER... This is not an extension bug but rather a Qt issue, in fact:

• They don't check for IsStatusNotifierHostRegistered property value (and changes) (this partially happened before a change by @ilya-fedin)
• They don't check for StatusNotifierHostRegistered signal emission to update the state of the dbus menu availability
• They don't update the state of the dbus tray support availiability (and the current icons mode) based on that.

So, really nothing we can do at extension level. So I'd rather suggest you to report a bug to Qt.

Also, the position of the menu is something that we don't control in the extension, a part passing to the shell the event when the user clicked, so we can't really do anything at this level, but I've proposed a fix upstream.

[ilya-fedin]

• They don't check for IsStatusNotifierHostRegistered property value (and changes) (this partially happened before a change by @ilya-fedin)

It's not necessary to listen for its changes if it's not queried at all - listening for watcher changes should be enough. In other words, my change made the chance of the legacy API usage lesser, in case the watcher is registered while the host is not yet: before the change it would fallback to legacy tray icon in such case but now will use SNI anyway.

The root problem is it doesn't listen for watcher changes, which I reported long time ago as https://bugreports.qt.io/browse/QTBUG-94871. Personally i don't really believe they will fix it, it looks to me like a big refactoring of abstractions is needed for that to happen (would really like to be proven wrong!) and they apparently don't treat the issue as a high priority...

[3v1n0]

Thanks for the info, in any case, the fdo API says that having a watcher doesn't mean that we've an host, while the host availability is what should make apps to consider that they can use the appindicator.

[ilya-fedin]

having a watcher doesn't mean that we've an host

I'm doubt situation of a watcher without a host exists nowadays

while the host availability is what should make apps to consider that they can use the appindicator

The API has evolved since it was described on freedesktop website, e.g. implementations don't own a bus name nowadays. There's also an addition for xdg-activation support. All the changes happen through the reference KStatusNotifierItem KDE framework and this freedesktop page is highly outdated.

[ilya-fedin]

I added some more quick improvements so in 6.5.7/6.7.2/6.8.0 it should automatically update dbus availability on Wayland at least. On X11, applications will be able to manually update the used backend by recreating QSystemTrayIcon object, e.g.:

// assuming m_trayWatcher is a std::optional<QDBusServiceWatcher>
m_trayWatcher.emplace("org.kde.StatusNotifierWatcher", QDBusConnection::sessionBus());
connect(&*m_trayWatcher, &QDBusServiceWatcher::serviceOwnerChanged, this, [=](const QString &serviceName, const QString &oldOwner, const QString &newOwner) {
    // assuming m_trayIcon is a std::optional<QSystemTrayIcon>
    m_trayIcon.emplace();
    m_trayIcon->setIcon(...);
    m_trayIcon->setTooltip(...);
    m_trayIcon->setContextMenu(...);
    m_trayIcon->show();
});