search

flatpak / xdg-desktop-portal

Desktop integration portal
https://flatpak.github.io/xdg-desktop-portal/
GNU Lesser General Public License v2.1
598 stars 193 forks source link

StatusNotifier portal #266

Open TingPing opened 5 years ago

TingPing commented 5 years ago

Going through common permissions one that is extremely prevalent that we have no answer for is tray icons, specifically StatusNotifier. So I just wanted to start a discussion on where this fits in and what we can do for it.

The API for this is here: https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/

I think this should be a pretty simple portal as we just want to proxy calls to StatusNotifierWatcher but filter out RegisterStatusNotifierHost() since that should be a privileged call, filter out the signals since they are noise, and also ensure StatusNotifierItem.Id matches the app-id.

Obviously users of this will have to handle errors and understand that the tray may not exist and we should have a signal to tell the app that the tray is gone or not.

As for where this will be implemented, it will be annoying to do so in libappindicator since its a dead library but we can just patch it I suppose. KDE has its own implementation where this would be handled. And there is a small GObject style lib (but not widely used) that we can implement this in and promote over appindciator (https://github.com/jjk-jacky/statusnotifier).

grulja commented 5 years ago

Support for this portal will need to be implemented in both Qt and KDE Frameworks. There are applications using QSystemTrayIcon API from Qt, which uses tray implementation based on Qt platform theme. If application is using KDE platform theme, then KStatusNotifierItem is used from KNotification framework. If a different platform theme is used (e.g. QGnomePlatform), then default QDBusTrayIcon implementation is used. Both use StatusNotifierItem API of course. Some KDE applications (e.g. Konversation) also use KStatusNotifierItem directly.

Since it's a DBus API, it should't be complicated to just do a different DBus call based on sandbox detection. I don't know how important this is for Gnome apps, sice Gnome shell officially doesn't support tray icons now, but in Plasma this is I think used frequently so if no one steps up to implement this, I volunteer to look into it.

matthiasclasen commented 5 years ago

Sounds like a good idea

TingPing commented 5 years ago

@grulja What is the difference between QDBusTrayIcon and KStatusNotifierItem?

grulja commented 5 years ago

Both basically do the same, just KStatusNotifierItem is a library, or a class from a library, allowing to apps use SNI without doing all the DBus work and knowing the DBus API. QDBusTrayIcon is Qt's implementation of SNI used as a fallback in case of platform theme doesn't provide their system tray support.

grulja commented 5 years ago

Qt's only API for system tray is in QSystemTrayIcon and this will internally use QDBusTrayIcon, or Window system tray or Mac OS system tray, this all depends on platform theme, just hidden under unified API.

jiri-janousek commented 5 years ago

As for where this will be implemented, it will be annoying to do so in libappindicator since its a dead library but we can just patch it I suppose.

There is Ayatana Indicators project which forked libappindicator and maintains it as libayatana-appindicator.

TingPing commented 5 years ago

There is Ayatana Indicators project which forked libappindicator and maintains it as libayatana-appindicator.

But they broke API so its not useful as a drop in replacement.

matthieugras commented 4 years ago

Any progress on this issue?

Mikenux commented 1 year ago

Is having this portal still necessary, or is the background portal replacing it?

TingPing commented 1 year ago

The background portal does not replace all functionality.

smcv commented 1 year ago

I thought SNI and other existing "tray-icon" protocols were problematic in sandboxed world because they assume either X11, or globally-scoped process IDs, or both?

Mikenux commented 1 year ago

The background portal does not replace all functionality.

What about adding other functionality to the background portal?

TingPing commented 1 year ago

I thought SNI and other existing "tray-icon" protocols were problematic in sandboxed world because they assume either X11, or globally-scoped process IDs, or both?

The PID requirement has been dropped from all implementations AFAIK.

X11 is only relevant for a few signals that involve like menu positioning, but I've never seen any app that uses that and those could probably just be dropped.

I think it is possible to portal a good portion of the existing protocol. I also think it is less than ideal. I wrote a whole thing about a replacement here: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/54

I lost the energy to push such a replacement and it needs buy-in from everybody to mean anything and I don't think it can get that.

Justinzobel commented 6 months ago

Ping. Is this work still in progress?