Version should not be part of window class (possibly Linux-only problem)

[kermitfrog]

Ambermoon.net currently reports it's WM_CLASS as
"Ambermoon.net v1.1.0", "Ambermoon.net v1.1.0"
but should be
"Ambermoon.net", "Ambermoon.net"

From the X Documentation (see https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS):

The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information.

The last part (identifying information) is the important one here.
Ambermoon.net uses the same WM_CLASS value as it's title, which contains the version. The information is used by applications like window managers to apply specific settings like "no border", always open on desktop 1, keep above other windows / the task bar, etc. to certain windows.

If the version information is present, these settings have to be manually updated on each update.
The WM_CLASS is independent of the window title, which may still contain the version or even change during runtime.

[Pyrdacor]

I researched this issue. glfw uses the window title as the class name by default. There is a possibility to change it manually. Unfortunately the glfw stuff is encapsulated inside Silk.net (a library I used for windowing etc). But I will add the possibility to this lib soon, if I am allowed to. The update will then come with one of the next Silk.net releases hopefully and I can integrate it into the next Ambermoon.net release.

[Pyrdacor]

I contributed to the window backend I am using and integrated a possibility to explicitly set the window class. They released the update yesterday so I can now implement a fixed window class for X11. :)

Will be part of the 1.4 release.

[Pyrdacor]

This should work in 1.4. I need some testers on X window systems to verify it.

[kermitfrog]

Yep, it does work now - thanks :)

[kermitfrog]

Regression!! Regression!!
It was fixed, but now the version is part of the window class again :(

[Pyrdacor]

Whoot? What version do you use?

[kermitfrog]

happened with at least with 1.6.3, 1.6.5 and 1.6.6. Didn't test for quite a while before that

[Pyrdacor]

Can you try some versions in-between to pin it down to some version range?

[kermitfrog]

well... now I'm totally confused...

I tried 1.4.0, 1.4.1 and 1.5.0 and all of them display the version as part of the class again!
I know one of them (probably 1.4.1) must have been the one that I tested and it worked fine.

To make sure, it's not because of some weird misconfiguration, I tested as my tmp user (whose home directory is in a ram-disk) as well - same thing there.

The only explanation I can think of is that it's also dependend on some system library that has been upgraded, but have no idea which :/

[Pyrdacor]

Maybe it is caused by glfw. I only give the class name as a hint to glfw and hope for the best. Maybe some glfw update changed the behavior?

[Pyrdacor]

I also think that the hint only works with X11. But I guess you are still using it. Maybe it is a bug in glfw with some recent update.

[kermitfrog]

Maybe it is caused by glfw. I only give the class name as a hint to glfw and hope for the best. Maybe some glfw update changed the behavior?

The only match for glfw, I can find on my system is part of Ambermoon.net - so that's probably not it (unless you retrofitted the old versions with a new glfw)

I also think that the hint only works with X11. But I guess you are still using it. Maybe it is a bug in glfw with some recent update.

Window class should work in Wayland as far as I know, but yeah - I'm still using X11. There's no doubt about Wayland getting better, but I still find something that's not working right every time I try it.

[Pyrdacor]

Another possibility would be that glfw uses some environment variable. There are two things: the class name and the instance name. Both can be set via a hint but I think I only set the hint for the class name. Could it be that the instance name is the important one here?

Can you try to set the environment variable RESOURCE_NAME to something while running the exe. It seems that glfw uses that variable if it is filled and the hint is not set. I only want to rule out any possible side effects.

I found this info here: https://nimgl.dev/docs/glfw.html. Maybe there is more.

[kermitfrog]

Finally got time for hobby projects again :)

I tried setting the RESOURCE_NAME variable, but that only sets the less interesting part of the WM_CLASS -- the one that's used for a specific instance of a window:

WM_CLASS(STRING) = "test", "Ambermoon.net v1.7.1"

vs.

WM_CLASS(STRING) = "Ambermoon.net v1.7.1", "Ambermoon.net v1.7.1"

Any relevant matching that I'm aware of, needs the other part.

[kermitfrog]

I took a look at your code (GameWindow.cs -> Run()) to see which functions you use and if I maybe spot something... as far as I can see, it looks fine.
Further investigation would need access to Silk.NET reference documentation, for which I was only able to find placeholders...
Did they actually get to version 3.0 without ever publishing any real documentation??!?!?

[Pyrdacor]

Well in the end it all comes down to the glfw hints I guess. And yeah the docu is pretty bad. :D

[kermitfrog]

In that case, I'll pause this for now.

As KDE Neon is finally done rebasing on the current Ubuntu LTS, I'll probably do either a major system upgrade or, after many years, a full reinstall within the next two weeks.. I wonder if that will change anything.

[Pyrdacor]

By any chance did you have time to test again? Would be nice if we could resolve this at some point.

[kermitfrog]

I tried with 1.9.0 - unfortunately the problem still exists :/