Feature Request: Stable tray panel positioning on Wayland

[symonbaikov]

Problem Description

On Linux Wayland, clicking the OpenUsage tray icon does not reliably open the panel under the tray icon. The panel may appear in a corner, near the wrong system tray item, centered, or at a compositor-chosen position instead of being visually anchored to the OpenUsage icon.

This is especially visible on GNOME Wayland with AppIndicator/KStatusNotifier tray support. Native window positioning APIs only work as compositor hints, and tray icon geometry is often unavailable or incorrect.

Expected Behavior

When the user clicks the OpenUsage tray icon, the OpenUsage panel should open in a predictable place:

• ideally directly below the OpenUsage tray icon, with the arrow pointing at the icon;
• otherwise in a stable fallback position that feels intentional and does not jump around.

Current Behavior

• The panel does not consistently position under the OpenUsage tray icon on Wayland.
• Tauri tray geometry can be unavailable or misleading on Linux Wayland.
• The compositor may ignore set_position / window move requests.
• GNOME AppIndicator/KStatusNotifier does not expose a simple, stable tray icon rectangle to the app process.
• Attempts to infer the tray icon location from pointer position or fallback geometry are not stable enough.

Environment

Observed with:

• App Version: OpenUsage 0.6.24
• OS: Linux
• Session: Wayland
• Desktop / Compositor: GNOME Shell 49.x with AppIndicator/KStatusNotifier tray extension
• Runtime: Tauri desktop app

This may also affect KDE Plasma, Hyprland, Sway, and other Wayland compositors depending on tray implementation and compositor policy.

Why not use only the native context menu?

A native tray context menu is usually positioned correctly by the desktop shell/compositor, but it cannot provide the current polished OpenUsage UI: usage bars, segmented controls, provider status, toggles, and the existing panel design.

Suggested Solutions

Possible approaches:

1. Stable fallback popup position
   Use a deliberate, stable location on Wayland when exact tray icon coordinates are unavailable, for example top-right or bottom-right of the active monitor. This is likely the most reliable short-term solution.

2. Optional native tray menu mode
   Add a setting that lets users choose a simpler native menu on Linux Wayland if they prefer correct native placement over the custom panel UI.

3. Layer Shell support
   Investigate wlr-layer-shell / compositor-specific layer shell support for Linux, where available, to anchor a popup-like surface to a panel edge.

4. Wayland popup positioning
   Investigate whether Tauri/wry can expose a proper Wayland popup path using xdg_positioner or compositor-supported popup semantics instead of moving a normal top-level window.

5. Desktop-specific integrations
   Consider KDE Plasma or GNOME-specific integration only if it can be maintained without fragile shell-extension patching.

Additional Idea

Add a Linux setting for tray click behavior:

• Custom OpenUsage panel, stable fallback position
• Native tray menu
• Future: custom panel anchored under tray icon when the compositor/toolkit supports it

I can provide logs, screenshots, and testing on GNOME Wayland if needed.