[StatusIndicator] Add method to get indicator icon screen rect.

[bruvzg]

Add status_indicator_get_rect method to get indicator rectangle in the screen coordinates. Usefully of positioning popups (existing methods only include mouse click coordinates).

[Mickeon]

I don't quite understand what this status indicator is, could you provide an example?

[bruvzg]

I don't quite understand what this status indicator is

System tray icons (StatusIndicator class):

[Mickeon]

Aah, roger that.

[Mickeon]

Docs are just fine now, can't speak on implementation

[akien-mga]

Code looks good.

[Riteo]

Is there another usecase, outside of a popup? I wonder if we could perhaps add just an open_popup method of sorts, as I don't see this playing well with Wayland (when/if it will be implemented) at least.

[Mickeon]

Can't think of any on top of my head. If not for a popup it could be used for other visual flair (e.g. item inside the main program window moving towards the taskbar). Very niche! A popup sounds more common.

[bruvzg]

Is there another usecase, outside of a popup? I wonder if we could perhaps add just an open_popup method of sorts

The only info org.kde.StatusNotifierItem provide is position hint (the x and y parameters are in screen coordinates and is to be considered an hint to the item about where to show the context menu), and existing StatusIndicator callback already include click coordinates (currently it's absolute mouse position, but probably it would make sense to switch it to the same position hint instead for consistency, but I'm not sure what's point it should return exactly). But ideally you should know both tray icon rect and popup rect to position it perfectly, I do not think there's any workaround.

as I don't see this playing well with Wayland (when/if it will be implemented) at least.

Until full multi-window support is implemented, it's going to be completely useless for Wayland anyway. But I plan to implement org.kde.StatusNotifierItem (since it will work with X11 as well).

[Riteo]

@bruvzg

Until full multi-window support is implemented, it's going to be completely useless for Wayland anyway.

Not necessarily, if there's an API for making "native" menus.

That said, I don't know the current platform APIs for this kind of stuff (if there's any) and probably we're going to make some non-screen-based ones anyways.

I'm only slightly concerned about the amount of duplicated/deprecated API surface we might have if we ever switch to (or just add) a window-centric API, which is what Wayland needs. We should really set up a meeting or something one day, as it's not a trivial matter IMO.

[bruvzg]

if there's an API for making "native" menus.

Most apps (at least on macOS and Windows) aren't using menus as popup (2/3 of indicators I currently have on macOS are fully custom popups). Not sure if there's any kind of native menu.

I'm only slightly concerned about the amount of duplicated/deprecated API surface we might have if we ever switch to (or just add) a window-centric API, which is what Wayland needs.

org.freedesktop.StatusNotifierItem use screen coordinates, so I do not think we have a choice. Also, how it can be window-centric when there's no window.

Edit: Other UI toolkits seems to handle it in the same way, e.g, https://doc.qt.io/qt-6/qsystemtrayicon.html#geometry

[Riteo]

@bruvgz

Most apps (at least on macOS and Windows) aren't using menus as popup (2/3 of indicators I currently have on macOS are fully custom popups). Not sure if there's any kind of native menu.

org.freedesktop.StatusNotifierItem use screen coordinates, so I do not think we have a choice. Also, how it can be window-centric when there's no window.

Mh... Not sure about other platforms, but it looks like there's actually a native menu API for FreeDesktop in the indicator logic: org.freedesktop.StatusNotifierItem.Menu, which is described as OBJECT PATH: DBus path to an object which should implement the com.canonical.dbusmenu interface . This weirdly named interface is defined here: https://github.com/gnustep/libs-dbuskit/blob/4dc9b56216e46e0e385b976b0605b965509ebbbd/Bundles/DBusMenu/com.canonical.dbusmenu.xml

This stuff is ancient though, I'm not sure how much it's actually implemented but sway has a todo comment for that, so there's still some modern interest. We could investigate on whether KDE and GNOME implement it.

Edit: Other UI toolkits seems to handle it in the same way, e.g, https://doc.qt.io/qt-6/qsystemtrayicon.html#geometry

Note that Qt has also a QSystemTrayIcon::setContextMenu(QMenu *menu) method. Which makes it possible to do so without having direct access to the screen from the application, AFAICT. Note that it uses "custom" popups so they definitely don't use this DBus API.

I would really like to avoid adding another screen-based API, but if it becomes too complicated we could let this one in too and offset the problem to when we'll have to manage the other ones anyways.

[akien-mga]

So this got stale, can we reach a consensus?

It seems to me like we don't know yet whether FreeDesktop allows more than just screen coordinates for this API, so I feel like it might be best to merge this for now, and if we figure out another API would be better in the future, we can implement that and deprecate this one? Or have both options, which seems to be what FreeDesktop may offer?

[Riteo]

@akien-mga

I'm pretty sure FreeDesktop indeed offers the APIs discussed above, as QT (or at least, telegram-desktop) tries to use it (by looking at dbus-monitor). I haven't tested this, but I suppose that KDE would show a native-looking menu.

That said, the only usecase provided here is making menus, which has already been addressed in #89588. It offers a new generic interface which allows platforms to handle menus however they please, without exposing platform-specific stuff to scripting.

In fact, by looking at the code it looks like the Windows backend is fetching the icon rect just fine through this new interface.

In any case, if there's still further need for this specific API, I'm not against merging this, as my main concern (generic menu handling) has been resolved.

[bruvzg]

The primary purpose of this PR is positioning and displaying custom non-menu popups (which is not fully supported by DBus, it only provides click coordinates, not icon rect).

You might also want to display some sort of popup without user clicking the tray icon (which seems to be impossible with DBus, but can be done on macOS and Windows, and will require icon rect).

[Riteo]

@bruvzg you're right, DBus does not expose that information.

That said, as there are still usecases for other platforms outside of menus, so I'm all for it :D

[akien-mga]

Thanks!