Window and application icons

Changing the app ID is not a hack and the recommended way go do this.

Can you describe your use-case? What is your client, why do you need to change the icon?

I was thinking about this and I wonder, how would Wine have unique window icons? Wine, Xwayland, GLFW, SDL all would benefit from this optional icon. I do think wl_buffer is appropriate and we can even have more than one pixel format, unlike X! There needs to be a way to specify different icon sizes as well. Probably best to have it as its own protocol. Xwayland has icons on GNOME, but other clients can't (yet) benefit from this.

That still doesn't answer the question: what is the benefit of icons, instead of just specifying the app_id and letting the compositor get the app icon from it?

How would the compositor be given the content of the icon

The desktop shell also needs the icon, for example to show the app icon in the search results. Loading the icon based on the application id seems like a really good compromise.

I was thinking of just making the icon a wl_surface with a special application icon or window icon role

Effectively, this means that there are two icon sources. The desktop shell will have to stick with icons loaded based on the app id, and the compositor will use icons provided by clients.

X11 clients can provide window icons and we are constantly reminded of this ~~amazing~~ feature in a form of bug reports, e.g. application icons in the desktop shell and the compositor look different, etc.

why do you need to change the icon?

One use case of dynamically changing the icon is to convey dynamic information. Chat apps often have a little marker in the corner of their icon for example if there are unread messages. It's imo quite useful when I use Windows.

Of course there is now the question if and how that should be supported on the Wayland side of things. But considering that the information can change somewhat fast, there needs to be SOME way of telling the environment that the icon should change now, but that doesn't need to be in the compositor.

On the one hand, it would make kinda sense imo to be in the compositor, since the it is probably the only one who is also going to know which programs may be interested in this (e.g. a taskbar, dock etc.). On the other hand, this could also be done via e.g. a small DBus bouncer.

This kind of information is usually conveyed either via notifications or via xdg-activation on Wayland.

Notifications: Were you ever on e.g. a big Discord server? If you have a few thousand people in essentially one big chat room (you get that with big communities), you would have essentially a form of notification spamming (and is also the reason why such apps turn notifications off for so big ones except if you are explicitly mentioned/tagged).

xdg-activation: Isn't this only for when you start an application? Because that is not what I am talking about.

xdg-activation can be used for marking toplevels as "urgent" on compositors that have such a concept by creating a token without a serial, then using the token to request activation.

Ah, you mean that the icon (or whatever it is represented as) then starts to blink or something like that? That's conveys too strong of a notion. It basically says "I have something you must react on now!", but this often isn't the case. In such a case you just want to say "I have something for you, but I don't care when you act on it.".

Alright. I'd suggest you try to pitch this to compositors then. I think some of them will NACK support for "activity" icon changes.

If you find a compositor willing to implement this, feel free to submit a wayland-protocols MR.

Well, since it seems to be the end of the message chain, I will leave this here for reading through it by other, about what each way represents (via a metaphor of a co-worker wanting to tell you something):

notification: the person comes to you and starts talking (or shouts across the room)
"blinking" activation (or however it is represented): the co-worker stares at you extensively and maybe even waves aggressively
a small icon change (like a number in the corner)): leaving a note on the desk
none of this (I don't know other ways of trying to get users attention (be it subtle or unsubtle): the co-worker doesn't tell you what they wanted something and expects you to know that they wanted somehow

Changing the icon is the worst solution to that problem. The reason why we have for example a notification API instead of you arranging some weird surface somewhere is because that gives compositors the chance to display a notification as they see fit. Similarly you would want an API which tells the compositor "there is N new things here" or "I made N percent progress". Unity already has such an API (https://wiki.ubuntu.com/Unity/LauncherAPI) but I'm sure this use case could be made platform agnostic with xdg-desktop-portal (https://flatpak.github.io/xdg-desktop-portal/portal-docs.html) similar to the Notification portal.

that would probably work too

@i509VCB , your opinion on all of this?

For the purpose of a notification marker or progress tracker, that probably makes more sense as it's own protocol and probably not use the icon, makes sense if a compositor wants to display it's own style of notification marker or not even place it on the application icon.

I would probably change the concept of this possible protocol to be related to cases where the app id really can't be used to derive an icon.

Given the feedback I've seen, the primary use case I've seen for allowing an application to set arbitrary window or application icons is where there is no way to associate precisely a specific application and it's .desktop files.

Yari brought up Wine earlier which makes sense, I may pop into the wine mailing lists or where ever to ask about their opinion on this type of thing. XWayland could be another use, but my experience on KDE shows that they just set the icon from X, so that can be implemented probably without much hassle.

I primarily started as a Java developer and I've noticed at least on Wayland that applications run through the JVM do not have their icons set reliably. Swing and JavaFX, the two primary windowing apis in the Java ecosystem rely on you setting the icon through their own APIs. OpenJDK's implementation of Swing is still on X and JavaFX has no Wayland implementation yet, but keeping the door open here for those types of platforms to accurately provide the compositor with an icon is useful.

Yari brought up Wine earlier which makes sense, I may pop into the wine mailing lists or where ever to ask about their opinion on this type of thing

Wine creates .desktop files for Windows applications, so app-id should work.

XWayland could be another use, but my experience on KDE shows that they just set the icon from X, so that can be implemented probably without much hassle.

Yeah, XWayland doesn't need it, the Wayland compositor's XWM can just get the icon from X11 if need be.

applications run through the JVM do not have their icons set reliably

Java should add a way to set app-id in their windowing APIs.

Java should add a way to set app-id in their windowing APIs. Multiple pain points about that:

Java does not have a concept of app-id.
Java apps get normally distributed as .jar files which contain EVERYTHING (including the icon) they need to run except the JVM (and their standard library) itself.
You are asking here to change platform-independent APIs to change after at least a decade because one platform wants to be different. Although I guess they could implement it by just using the filename of the icon as app-id.
If you actually add such an API, shouldn't you be able to change the app-id at will at runtime? Wouldn't that just create the same problem you are trying to solve by not providing an API to change the icon?

X11 has a concept of "class". app-id is the Wayland equivalent, with the added constraint that it should match the .desktop file. Does Java provide a way to set the class already?

A lone .jar won't integrate well with most Linux desktops anyways, since it's missing at least a .desktop file.

I'd rather not design new protocols for legacy applications. Anyways, if Java APIs don't support Wayland, this whole discussion is moot anyways.

In case you don't have a .desktop file, Java just uses the name of the Main-Class as class.

Given it's pretty unlikely this is going to be considered, I am going to close this issue.

If I do find a scenario where the .desktop file is not possible, then I'll resurrect this issue.

Also if this is the convention, it may be worth noting this convention somewhere for looking up the icons?

closed

Not able to set an icon for a window is inconvenient for AppImages, since most of them will not have a desktop file in XDG_DATA_DIRS.

@i509VCB please reopen:

@qydwhotmail gave a valid and very real scenario where the use of a .desktop file is not possible
Another scenario is desktop environments that do not use the concept of .desktop files at all because they are not following the XDG philosophy of doing things (e.g., GNUstep, helloDesktop, etc)
Yet another scenario is multi-window, cross-platform applications that want to display different icons for the different windows
Currently, Qt setWindowIcon is broken and cannot be fixed by Qt unless this is fixed in the Wayland protocols: https://bugreports.qt.io/browse/QTBUG-101427
Being able to set the window icon programmatically from within the application is functionality needed for consistent functionality of cross-platform applications

Thanks!

I probably won't be driving the creation of a protocol for this feature (I have other protocols I need to work on getting in upstream). I'll open it but I probably won't be talking much here (well unless the maintainers close it due to becoming settled).

I'll describe how this could be done:

Any proposal not using .desktop files will likely be rejected from the xdg namespace. Therefore this protocol should just go to ext namespace to avoid that step. The protocol still lives in wayland-protocols, but it does being up the question of does a protocol with an xdg namespace have a sort of extra prestige.
This protocol won't be something you can expect to see everywhere. I'd suspect gnome would not implement this, unsure about kwin, wlroots would depend on the specific downstream and same with Smithay (whether these two provide helpers in library is a different question).
Similarly on the client side the toolkits would need to implement this. Would GTK implement this? I don't know. Would SDL and winit implement this? Probably (begrudgingly in the latter case). Would Qt implement it? Assuming it isn't 2000 lines if code like the xdg-splash proposal then possibly. You end up with a situation that is very close to the situation around server side decorations.
Even if people do want this feature, is it worth doing if it isn't considered standard? Kind of a question like "is a standard really a standard if almost none of it has to be implemented"?

You end up with a situation that is very close to the situation around server side decorations.

Perfectly reasonable. As an application developer, the impression I get is that things seem to be bifurcating between "the reasonable people" and "GNOME, who I already lost interest in supporting my applications on for other reasons". (such as what a sloth GNOME Shell is in VirtualBox and the "you're either with us or against us"/"there's no such thing as a DE-agnostic application" attitude I've seen out of people like mccann.)

Do not turn this into personal attacks.

First, thank you very much for your 2013 talk. I've pointed so many people at that.

Second, I was giving two data points for why, as a software developer, supporting GNOME users in my unpaid hobby time has become an increasingly unappealing thing to do in the years since GNOME 2.

I do not daily-drive GNOME and, every time I've had to debug something in GNOME, it's performed so poorly in VirtualBox that it's been very demotivating. (Grab an OSBoxes image for Ubuntu and try it yourself if you don't believe me.)
Responses like this one give me the impression that GNOME, as a community, is hostile to developers who don't want to either make GNOME their primary target platform or develop a different frontend for each desktop. (That's the response by mccann that I was referring to.)

Those are my sources. I've now cited them.

I'm not attempting to judge or accuse. I'm just giving examples for why, as someone who doesn't daily-drive GNOME, I find the prospect of supporting my creations under GNOME unappealing.

I intentionally did not say anything about decisions that only affect me as a user, not a developer.

As a developer who is generally optimistic about Wayland, my biggest problem with this is the self-containedness angle.

It makes sense for .desktop files to handle things that are unarguably about desktop integration, such as file associations and how the application appears in the launcher, but it makes less sense to make them mandatory for things that are perceived as part of the application window, as the titlebar icon still is on a desktop using server-side window decorations.

Last I checked, KDE's "progess bar in taskbar button" support was based on Canonical's Unity DBus Launcher API, where you need a .desktop file to tie the app to the API (needlessly introducing a point of potential naming collision, no less) and my reaction since then has been simply to not use it. It's just too annoying to not be able to test-run my PyQt creations in a "completely self-contained inside the ~/src folder. No installation" configuration.

To me, this decision defines desktop integration in the same way as something obviously ridiculous like "If you don't install MPV's .desktop file or don't do it correctly, then the compositor won't allow it to request a fixed aspect ratio for its video playback window," or "Your application won't get a taskbar entry at all without a .desktop file because that's also desktop integration". (That latter one isn't as ludicrous as it seems on its face. Whenever you manually run a command from the launcher and expect it to have a GUI and it's a CLI-only thing, that's still a "task". We're just used to that UX wart. Another example would be double-clicking a .mp3 with no embedded cover art when you haven't yet reassigned your MP3 association to something other than MPV.)

Given my attitude toward making it easy for people to develop and run my creations without having to install a .desktop file, if this functionality remains as-is, I'll likely just adopt a "Works for me under XWayland/The bug is in Wayland, not in the app" attitude toward having an icon. (Hell, for my GOG.com games, I intentionally avoid installing the .desktop files because I don't like letting arbitrary third-party code like Mojosetup finger-paint in my desktop. Instead, I just unzip gog_whatever.sh and run the relevant stuff inside Firejail. We shouldn't be going back to a world that incentivizes something like Quarterdeck/Norton CleanSweep)

It boggles my mind that things like Steam and Lutris must, I assume, install .desktop files with Hidden=true or OnlyShowIn=Lutris if the user has already expressed a preference not to create launchers, purely to get an element of the window working that Just Works™ on every other platform. We already run into enough games that assume full-screen operation and display with the default X window icon in the taskbar. (Not to mention that my experience has been that things like the search field in KDE's launcher plasmoids can be a bit iffy about ignoring launchers the user has requested to hide.)

It also reminds me of how, under X11, there's no guaranteed way to map an X connection back to a PID to make better alternatives to tools like xkill. (cgroups don't handle telling apart an application the launcher spawned from some child application it then spawned.) An application using CSD can still draw its own icon in its titlebar if it so chooses, but the taskbar may or may not show it, depending on how the user chose to set it. What's worse is that, unlike _NET_WM_PID, the decision to "hold it wrong" is entirely in the user's hands and there's nothing the developer can do about it.

Likewise, for all that he's abrasive, opinionated, and generally of the opinion that Wayland will be fundamentally broken until it reaches feature parity with X11 without relying on things like XDG portals, probonopd is also the creator of Appimage... an application distribution format that, like statically linked EXEs on Windows, makes the use or non-use of external update managers and .desktop files entirely the user's choice.

To be perfectly honest, the "Is SDL2 going to have to bite the bullet and fix something Windows and macOS developers don't have to deal with again?"-ness of this reminds me of GNOME refusing to implement the decoration protocol... except, in this case, I imagine it'd be more in the vein of detecting when not sandboxed, using xdg-desktop-menu to inject a temporary .desktop file, and using some kind of exec $0 --inner-esque hack to ensure cleanup on program exit can occur.

(Not that doing so solve the "I don't want arbitrary applications doodling in my launcher menu" problem. Maybe check for a D-Bus daemon that can do the creation and cleanup for the application? ...but Firejail doesn't seem to have copied Flatpak's support for fine-grained D-Bus filtering yet. Hmm.)

A perfectly reasonable stand, I think. Since this is already a relatively widely used and useful in a number of common situations, it would make sense to implement it.

[delegation is unreliable and counterintuitive]
Having the icons bear no direct connection to the runtime, but rather specifying an app id that might or might not have a desktop file in the user's environment and delegating the icon lookup to some other process? It is not only unreliable, but also not logical, and impossible without creating desktop entries for one-time use applications, which is NOT what they were made for.

[it contradicts desktop entry specification]
Desktop files are useful for informing the environment of some static information about installed programs - file associations, launcher icons, descriptions in different languages, search keywords, so on, but a window icon, just like the window title, is a runtime variable. Creating the desktop file for each possible window icon makes no logical sense if you consider the desktop entry specification. It clearly states, for example, that there are 3 types of desktop entries: application, link and directory. One desktop entry per application makes sense. 10 entries for 10 windows of a single application with different icons - not really.

[so?]
One compromise (I'm not a fan of) could be to add some kind of "state-icons" variable to the desktop entries and use it to associate multiple icons corresponding to different states or windows in the application and then specify them at runtime. However, this does not resolve the delegation issue and depends on even more "set the icon, it's probably there, idk" from the application at runtime.

Really, though, just add the interface needed for an application to set the icon on it's own. The only possible reason I see to not do it is to avoid encumbering the protocol, but this is not overly complex and is already widely used in non-wayland environments, meaning that it is useful and even expected.

Hmm. I can't correct "unlike _NET_WM_PID" to "unlike setting _NET_WM_PID" because GitLab has decided that change would make my comment spam and refuses to accept it.

Ugh. And it won't let me remove the exec I accidentally put in. That should be "and using some kind of "Spawn $0 --inner as a child"-esque hack to ensure cleanup of the temporary .desktop can still occur on segfault." (I usually use $0 for "If no stdin, re-execute self inside xterm hacks, where exec is appropriate.)

...and it won't let me correct "doing so solve" to "doing so solves".

reopened

Any proposal not using .desktop files will likely be rejected from the xdg namespace.

Why? As stated above, .desktop files are not suitable for all scenarios in which applications want to set (different) icons on windows.

Here is an example from a Windows application:

These windows are all from the same application and are shown alongside each other. Each window has its own icon. (You do not launch three separate applications, these are three window types in one launched application.)

Let's say this is a cross-platform application and its developer wants to achieve the same on Wayland. Why should that developer have to litter no fewer than three .desktop files into the system, just to be able to show the icons?

LibrePCB has the same problem with Wayland. While working on a PCB project one typically has 3 windows open: the main window, the schematic editor and the board editor.

The window icons help to find the correct window in any taskbar or other window navigation feature. I'm really disappointed about the mindset that there's no need to set the window icon. And .desktop files won't help here, as the icon is not the same for all windows and also it wouldn't work for portable bundles (like AppImage) or *.tar.gz binary releases. So this is not a solution at all.

Btw it's just one of several problems we have with Wayland, therefore we still enforce LibrePCB to run with XWayland. It's a shame, but I feel totally helpless against such decisions made by Wayland and using XWayland is the only reasonable option (which even works perfectly fine)...

Why? As stated above, .desktop files are not suitable for all scenarios in which applications want to set (different) icons on windows.

Maybe I was too jargony there: something for set_window_icon wouldn't be able to live in xdg-shell and would need to end up living in an extension protocol like xdg-decoration because some members of wayland-protocols would reject it from being added to xdg-shell (Every window on desktop compositors is an xdg-toplevel).

This isn't me saying it will never get merged, but that as a result of how governance works in wayland-protocols: to have the protocol xml in tree it would need to exist as a sort of ext-toplevel-icon protocol of sorts with a ext-toplevel-icon extension interfaces that extends xdg-toplevel.

The window icons help to find the correct window in any taskbar or other window navigation feature.

Is the issue that each window appears under the same icon on task bars or that to have separate icons on only the windows, you'd need three things on the task bar?

The window icons help to find the correct window in any taskbar or other window navigation feature.

Is the issue that each window appears under the same icon on task bars or that to have separate icons on only the windows, you'd need three things on the task bar?

Well, of course with window grouping in the taskbar it's impossible anyway to have three separate icons in the taskbar. But luckily many desktop environments allow to disable grouping so the user is still able to see each of the three windows in the taskbar, with their corresponding icon. Even though many taskbars group windows by default, this doesn't mean the window manager doesn't need to support separate window icons.

Anyway, as already mentioned in the discussion, this is just one use-case which is currently not possible with Wayland. The main issue from my point of view is that standalone binaries (like AppImages, *.tar.gz binary bundles, or simply locally built applications from developers) are missing the window icon because there's by design no .desktop file for them. As an application developer, I can't believe that I have to "install" the binary built during development with a .desktop file to get icons working.

As an application developer, I can't believe that I have to "install" the binary built during development with a .desktop file to get icons working.

*nod* I just chose not to use the "progress bar in taskbar entry" support in KDE Plasma because it requires a .desktop file.

Even if I'm developing something that's meant to be installed, it's terrible developer UX when iterating on a git checkout.

Well, of course with window grouping in the taskbar it's impossible anyway to have three separate icons in the taskbar.

Libreoffice and Kicad (when running eeschema and pcbnew standalone) do this by setting the app id to something else to result in three different icons on the task bar. Now it would be nice if there were a way to describe a grouping, like eeschema is under kicad and if the taskbar desired, put both eeschema and kicad in the same spot on the task bar but then use each application's own icon in the window icon. If you could show me what you are desiring with the task bar here it would be helpful.

Anyway, as already mentioned in the discussion, this is just one use-case which is currently not possible with Wayland. The main issue from my point of view is that standalone binaries (like AppImages, *.tar.gz binary bundles, or simply locally built applications from developers) are missing the window icon because there's by design no .desktop file for them.

As an application developer, I can't believe that I have to "install" the binary built during development with a .desktop file to get icons working.

This is definitely something I can sympathize with as I have some application development stuff I am doing myself (although whether I will ever get it out the door is a different question), seeing the Wayland icon in Plasma is sometimes confusing.

It would be tempting to have a set_dev_desktop_file request to send to the compositor. Sadly how the .desktop file is used is largely compositor dependent. In my own setup the task bar and compositor run in different processes. I have no real nice way to communicate the custom .desktop file between the two processes at the moment. Would this be acceptable for xdg-shell? No real idea.

At the same time if a sort of set_dev_desktop_file existed as portal, I'd still have concerns about communicating that info to an independent task bar process without adding extra code in my stuff again. Gnome might be more happy with the portal, but we just shifted the problem from the speaking wayland to speaking dbus.

Now if the implementation had a taskbar in process this would be shooting fish in barrel, but not everyone does that. What this specific issue gets into is the somewhat unclear relation between the compositor and shell components in each implementation (which can range from full isolation, partial: the task bar is seperate but the compositor does some stuff for window icons, or entirely in process: task bar and window icons are done by the compositor).

Also if a set_dev_desktop_file request existed, what stops someone from just always using it? Does the compositor arbitrarily decide whether that request is being used invalidly and ignores it?

Also if a set_dev_desktop_file request existed, what stops someone from just always using it? Does the compositor arbitrarily decide whether that request is being used invalidly and ignores it?

Well, first, I'd worry about what happens if more than one .desktop file with different icons point to the same command. Am I going to randomly see my Firefox showing a GOG.com icon because of the firefox --new-instance -P gog_purchases shortcut I set up for making an exception to my anti-tracking, anti-popups tweaks which break PayPal's popup-based checkout flow?

I may not use a lot of web-based stuff, but I can see that being a problem for people who are used to the "Pin Website to Home Screen" behaviour available on mobile devices.

Solution for that aside, I imagine it'd work similarly to how QIcon::fromTheme(const QString &name, const QIcon &fallback) works. The compositor would be expected to let the installed .desktop file take precedence over the hard-coded one.

Well, of course with window grouping in the taskbar it's impossible anyway to have three separate icons in the taskbar.

Libreoffice and Kicad (when running eeschema and pcbnew standalone) do this by setting the app id to something else to result in three different icons on the task bar.

I think here you're talking about separate processes, of course they can have different icons. I am talking about one process with multiple windows. And no, we don't want to split our application into separate processes because that would lead to very bad user experience.

It would be tempting to have a set_dev_desktop_file request to send to the compositor.

Please please please no, this sounds like a horrible API to me. Why a desktop file for something simple as an icon? Please don't reinvent the wheel and make things more complicated than they are.

In the end, all we want is to have a working QMainWindow::setWindowIcon() function from Qt (and its respective function from other toolkits). So don't think about us (application developers), think about what API Qt developers need to get it working. I'm pretty sure they don't want to handle with desktop files for that.

I really don't understand the problem. We already have QMainWindow::setWindowTitle() which also controls window decoration from within the application (I suspect it works on Wayland?). Probably nobody would argue the window title shall be set in a desktop file. Since the window icon is displayed just next to the window title, and they are strongly related to each other, why handle them different? They are basically the same thing, just of different data type (string vs. image). MS Windows works this way. macOS works this way. X11 works this way. Only Wayland makes our life hard.

Side note: If theme-dependent icons are needed, this is a matter of the application. All we need id setWindowIcon(), then we can implement theming by ourselves if needed (for any complex scenarios of multiple windows and multiple themes).

To be honest, I don't like discussing this simple topic any more as it feels like wasted time to me. I wrote down all my arguments and thoughts, but now it's up to you to decide. If you implement such an API, I'd highly appreciate it. If not, I'll continue enforcing XWayland for LibrePCB because I have no nerves (and time) to receive bug reports from our users about behavior intended by Wayland developers.

If you implement such an API, I'd highly appreciate it.

I did state earlier I am busy with some other protocols I am adding to this repo. Largely it's the single client and server implementation you'd need for inclusion that I don't have time for (probably Qt and then one server).

I can provide some advice for how such a protocol can look of course.

Hi there, I'd like to give some input on this too.

(i509 might recognize me, this issue was created as a result of one of the times I mentioned this on discord as one of my pain points with Wayland and part of why I still use Xorg. I still think that way.) I wanted to comment on this matter again here earlier but I never got around to (and was somewhat afraid it would have been hopeless effort that at best KWin would listen to)...

But, let's start... First, as we probably all know, not every desktop environment, compositor, shell, etc. currently shows window or application icons, whether on X11 or Wayland. I currently use KDE Plasma 5, which does show both. Others might only show one of them, or none and not be interested in this at all. But Wayland shouldn't be only for those who do or those who don't... I'll talk in the context of those who currently do, here.

Wine creates .desktop files for Windows applications, so app-id should work.

In reality, this doesn't actually work for a number of reasons... Wine currently runs through Xwayland so you don't notice that, yet that is.

It only creates .desktop files for start menu items... not all Windows applications create those either (even portable applications exist on Windows as well but there's even ones with an installer that don't), the user or prefix manager might have disabled winemenubuilder so that the application menu and MIME associations aren't spammed with Windows stuff (steam does this AFAIK), and the executable that actually opens the window might not be the same as the one started by it (think, launchers, which exist on native Linux as well), the application might have a different icon compared to the start menu icon (some start menu items have an icon indicating they just start the application) and it might want to change the icon depending on context or open sub-windows with different icons (as was mentioned before in this thread).

Sub-applications without application menu entries exist on Linux as well (think report-gtk, which has no icon on wayland).

A lone .jar won't integrate well with most Linux desktops anyways, since it's missing at least a .desktop file.

What would "integrating" even mean here? I mean, for a simple program that doesn't have a file or URI handler or similar, how it looks is all there is (although I suppose pinning a running application to the taskbar or similar is a thing). Forcing it to have no icon for the reason that it wants to be portable seems like a bad solution for anything.

As for not supporting Wayland yet, project Wakefield is working on that and doesn't seem too far away, I'm sure they'd appreciate this being implemented.

A better example though might be Minecraft. Minecraft also runs on Xwayland currently. (and in fact window icons are part of the reason why it couldn't run natively out-of-the-box for a while, since GLFW errored when trying to set the window icon on Wayland because it isn't and currently can't be implemented)

Minecraft needs a launcher to run. In modded Minecraft, more specifically modpacks, frequently the window and application icon is set to the modpack logo.

There's also the MultiMC launcher and the forks of it that display the instance icon as the window icon for their config window. This is currently broken on Wayland. Worse yet, the portable package doesn't have an application icon either. It does on X11.

But, even an application part of the GNOME project would be affected by this! More specifically, GIMP. GIMP sets the window icon to a preview of the currently opened file:

GIMP currently still uses GTK2, and goes through Xwayland as well as far as I can tell.

There would probably have to be some way for whatever handles the icons to figure out whether a set icon is the same as the .desktop icon and to use a themed version instead?

I'd love to help here, but I'm not very experienced in Wayland (or KWin) internals or designing a Wayland protocol, and not really interested in handling a matter that seems like it could easily get as political as the CSD thing.

To be entirely clear:

Any desktop which supports sandboxed applications must not support this kind of protocol. Letting the app change the icon can be abused to trick the user into thinking it's another app.

I will make sure this gets NACKed from the GNOME side and I don't expect any other desktop environment to support this either.

Letting the app change the icon can be abused to trick the user into thinking it's another app.

???? You can do that on wayland RIGHT NOW, so it doesnt change that flaw in ANY way... you just set the .desktop to point to another icon of another app... (pls think first)

Yeah. Political.

It's impossible for a flatpak app to change its own icon and that's by design to ensure the security properties of the system. This protocol breaks this.

Can we please at least make it so an application can self-publish a fallback choice for when it would otherwise present whatever appearance the compositor uses for "no icon"?

I keep pointing at QIcon::fromTheme(const QString &name, const QIcon &fallback) because it looks like a reasonable way to not drift things toward penalizing portable apps and complicating iterating on test builds in git checkouts.

EDIT: Also, that didn't occur to me at first because it seems like all an application needs to do in order to undermine the wetware-hacking prevention is to tell the compositor they're going to draw headerbars and then implement their own custom icon code. This was actually one of the arguments made on the Arcan blog in favour of forced server-side decorations.

Without getting into the technical arguments, GNOME doesn't necessarily need to NACK everything it doesn't want to support. For instance xdg-decoration will not be supported by GNOME, however it was not NACKed (on the contrary, GNOME members helped ship the protocol).

Also please note that while @swick is a GNOME contributor, they do not represent GNOME in terms of wayland-protocols governance. In other words, their opinion here should not be taken as the official GNOME stance. I do not want to dismiss @swick's contributions or involvment, just want to make things clear to people not too familiar with wayland-protocols.

It's impossible for a flatpak app to change its own icon and that's by design to ensure the security properties of the system. This protocol breaks this.

Then make it not break it

(if i need your to more explain, here is: if it in flatpack NO, just like old protocl that limit to .desktop yes this break this feature on flatpack, but if security is NR.1 there is NO too way to do this)

Any desktop which supports sandboxed applications must not support this kind of protocol.

Any kind of sandboxing could easily intercept/disallow the call to set custom icons on windows. It would still break functionality for applications like this

but at least the breakage would be limited to sandboxed applications and would not affect others.

This is completely ludicrous.

GNOME supports client side decorations, and refuses to implement server side decorations.

Yet applications setting their icon is somehow a security issue impairing ability of users to identify the application.

I will believe this is an honest concern when GNOME drops client side decorations.

Window and application icons

Child items ...

Activity

Admin message

Admin message

Window and application icons

Activity