Can apps really not set an arbitrary icon?

[Lampe2020]

I've seen that Firefox Developer Edition fails to set its icon on KDE on Wayland (even though I created a .desktop file for it), so it has the Wayland logo instead. But I wrote a PyGame-based maze editor and it has no .desktop file anywhere, but still, the icon I generate in a pygame.Surface from filled polygons is correcly displayed in the title bar and task bar. Same with the AppImage for Modrinth, which correctly shows the Modrinth logo in all places I expect it to and Minecraft itself (the actual java-based game, not the launcher) also shows the correct icon.

In the following screenshot you can see my maze editor running and in the background you can see the part of the code where it generates the icon.

[probonopd]

What is the "W" icon in the task bar?

[Lampe2020]

That's the Wayland logo, because Firefox Developer Edition (running on the other monitor not included in the screenshot) cannot set its icon correctly.
But my PyGame-based app can, even in the PyInstaller binary compiled while running X11/Unity7 before installing Wayland/KDE.

[probonopd]

That's really interesting, I wonder what is going on. Did KDE implement a proprietary workaround for the missing Wayland functionality?

[ximion]

No, it's most likely just running through Xwayland. Maybe running via SDL_VIDEODRIVER=wayland forces it to use Wayland.

[probonopd]

@Stehlampe2020 can you try to run your examples without Xwayland? What happens then?

[Lampe2020]

Are they run in XWayland? I just launched konsole (which I think naturally launches on Wayland if that's in use) and typed python3 mazepainter.py in the directory. So if it's running under XWayland, please tell me how to directly run it on Wayland.

[probonopd]

As @ximion said, maybe running via export SDL_VIDEODRIVER=wayland and then running it from the same terminal forces it to use Wayland.

(To be sure, you might want to test this on a system on which XWayland is not even installed.)

[Lampe2020]

To be honest, I've kind-of lost track of which comment thread is which because I wrote a comment under the ext-placement MR in Wayland, so I am currently being flooded with answers, where the ones from here just drown inbetween. I know I could unsubscribe from the Wayland MR but I want to follow it in almost-real-time.

[Lampe2020]

running via export SDL_VIDEODRIVER=wayland and then running it from the same terminal forces it to use Wayland

I tried that and indeed, now it has the Wayland logo.
But how could XWayland set the window icon, then? Or has XWayland disabled SSD and is making the X11-SSD as a Wayland-CSD?

[ximion]

KWin's Xwayland integration is just really good - pretty much everything that works on X also works via it (the Xwayland and KWin devs have done a good job!). All of this is reserved for X11 clients though, Wayland apps of course can't use it.

[probonopd]

So it seems that yes, Wayland native apps currently can't set an arbitrary icon, hence closing this question-in-a-ticket.

Let's hope that @ximion's proposed protocol will change that.

[probonopd]

Big thanks and congrats to @ximion for having gotten xdg_toplevel_icon_v1 merged.

Seems like the first compositor to actually support this is https://github.com/ValveSoftware/gamescope/, big thanks to @Joshua-Ashton. 🥇

• https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269
• https://github.com/ValveSoftware/gamescope/commit/ec0fb3a8a0244d2aaac2a63e01fd90cf3f34222b

Next steps:

• Wait until Qt supports it thanks to the work of @sodivad, then test if QWindow::setIcon is finally un-broken
• Wait for the compositors of KDE, Gnome, etc. to support it and test it there

[ssokolow]

Wait until Qt supports it thanks to the work of @Sodivad, then test if QWindow::setIcon is finally un-broken

Note that they say "If an icon name is set, we assume it's from an installed theme and provide the name, otherwise we provide buffers.", which suggests opposite semantics from QIcon::fromTheme(const QString &name, const QIcon &fallback) by design, so note-to-self to test whether providing a fallback for the icon being missing from the system theme is broken.

...because, to me, the best-case first-sight reading of those two descriptions is that you're stuck with two choices: Either provide an overridable icon from the system theme which will break in cases like Appimage or running from ~/src without installing or have Qt itself do the lookup and fallback, which won't be overridable and will always go for the fallback in cases where a sandbox'd application hasn't had the system icon store mapped into its view of the filesystem.

[probonopd]

Let's hope it will work with QIcon(const QPixmap &pixmap) to set a certain pixmap as the image without the compositor interfering with it in any way.

[ssokolow]

That should be the "otherwise we provide buffers" part.

Granted, the GNOME people removed the APIs for options other than "assume it's installed in the system icon theme and break otherwise" from GTK 4, so "GNOME XOR Windows 3.1" for icon theming support would still be an improvement.

Worst case, maybe I can code applications which try to query the icon from the theme themselves, send a name if they succeed, and send a pixmap if they don't. Thus being properly compatible with running from ~/src without depriving the user of the ability to override their icon themes when installed system-wide.