Details
-
Suggestion
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.13.0
-
None
-
KDE / kwin running with the Wayland backend.
Description
Since wayland-protocols 1.18, the set_app_id call got an amendment, which explicitly states that an app ID can be changed at runtime (nothing was stating the opposite before). And since it's a per xdg_toplevel property, I want to use it to change the application icon of my windows, based on the loaded document. I'll just quote my commit message from the wayland-protocols change:
LibreOffice is one big binary with explicit brandings for different
application modules. This is represented in X11 by a different
WM_CLASS setting for a window. The WM_CLASS is changed based on the
loaded document at runtime. As a result LibreOffice already offers
multiple desktop files with different icons, StartupWMClass
entries and application names.
This amendment of the set_app_id request just explicitly specifies
the use case to change a surfaces' app ID at runtime, so a compositor
implementor is made aware of it. Just as the WM_CLASS, a change of
the app ID should result in an update of the propertes of a surface
depending on the app ID, like the window icon specified in the
desktop file or a re-grouping of the surfaces in a task manager.
The original LibreOffice bug report is here: https://bugs.documentfoundation.org/show_bug.cgi?id=125934
So now I would like to get the app_id exposed via a QWindow API, so I can set the icon for my toplevel window. I did a little brain storming in comment #3 of the LO bug report:
"So thinking about this a bit more, maybe there should be an overload for QWindow::setIcon, which accepts the desktop file as a QString. IMHO it shouldn't accept a file name on other platforms as a convenience to load an icon. Or just allow a desktop file per QWindow? QIcon::fromTheme shouldn't work, as the icon is specified in the desktop file, not the theme. Maybe a QIcon::fromDesktopFile?"
Or maybe it should just be a an API exposed for a Wayland client like QtWayland already does for the compositor side?
I can hack something up, but IMHO the code itself will probably be trivial, after we could agree on the interface to implement, as it already works for the QGuiApplication::desktopFileName API. There is also some hacky LO patch, which uses KWayland to call set_app_id, but it creates a 2nd XdgSurface, which is wrong, but correctly sets the windows icon.
Attachments
Issue Links
- relates to
-
QTBUG-94729 Qt Wayland Client public API
- Open