How can I set the icon of my GLFW app in the task bar in my Ubuntu Linux 20.10 (Gnome 3.38.3)?
I have tried to create a so called Desktop entry in ~/.local/share/applications and that works for a simple gtkmm app but not for my GLFW app.
I have also tried to use glfwSetWindowIcon() but that has no effect.
The icon in the task bar is always empty. Here is what my task bar looks like with one gtkmm app with an icon from the corresponding desktop entry and below it the empty icon of my GLFW app which also has a similar desktop entry.
OS Name: Ubuntu Linux 20.10
OS Type: 64 bit
GNOME Version 3.38.3
Windowing system: X11
GLFW Version: 3.3
If that works, then it’s possible you are setting the alpha value to 0, so it ends up transparent - the icon format is 32bit RGBA (i.e. 8bits per channel, 4th value is alpha).
Checking the issues list I found an open issue concerning X11 and glfwSetWindowIcon():
I tried the icon.c test program and the the problem was the same there: There is no icon in the task bar (just a blank/transparent square).
The icon.c test program is supposed to change the icon every time space bar is pressed. This does not work either, and by that I think we can rule out the workaround that it would work if we just wait a while after program startup, as suggested in issue #1375.
We can also rule out the possibility that I was not setting the alpha channel of the icon pixels properly. I set the all four bytes of each pixel programmatically to 255 (or other values), and furthermore the icon.c test program also sets the alpha channel properly.
I also tested icon.c in Windows 10, and there it works as expected.
Note that for me, it is not critical that glfwSetWindowIcon() works. I would be happy if creating a Desktop entry would work instead. My gtkmm sample app also has a blank/transparent square as icon until I make a Desktop entry for it, but creating a similar Desktop entry for my glfw app does not work.
I found the problem with the Desktop entry: A desktop entry must have proper StartupWMClass. (The first entry you get if you run your application, and then from a terminal run xprop WM_CLASS and click on your application window.)
In my gtkmm test app I did nothing to set the WM_CLASS which meant that the WM_CLASS automatically got the same name as the executable, and it seems like in that case you don’t need to set the StartupWMClass in the Desktop entry.
However, in GLFW the WM_CLASS will be set by the third argument in the glfwCreateWindow() which is the Window title, and then the StartupWMClass must be correctly set in the Desktop entry.
You can also specify what the WM_CLASS property should be set to with the GLFW_X11_CLASS_NAME and GLFW_X11_INSTANCE_NAME window properties. This removes the dependency on the window title.
The fact that icon.c didn’t work indicates a potential bug given you are on X11 (for which I believe this should work), so it’s worth filing a Github issue unless @elmindreda thinks otherwise.
I can confirm that by running glfwWindowHintString(GLFW_X11_CLASS_NAME, "icon"); before glfwCreateWindow() I can set the WM_CLASS name to be “icon” which is then different from the window title, and by writing StartupWMClass=icon in the desktop entry I can set the icon.
But I was wrong in my assumption that I could leave out the StartupWMClass key from the desktop entry file as long as the WM_CLASS is the same as the executable name. There must be some other mechanism that makes that work for the gtkmm app.
The glfwSetWindowIcon() still does not work for me. However, I am happy with the desktop entry solution and besides I don’t know how to file a bug report, so I will not do that unless you insist.
