Application name in the Gnome 3 task bar says "hiro" instead of Application::name

I don't know why this is happening. The bsnes window is named "bsnes", but the task bar at the top of the screen calls the window "hiro" instead. This affects all hiro applications.

[Screwtapello]

If you run xprop in a terminal, your pointer should change to a crosshair, and when you click on any window, the properties of the associated top-level window will be printed out. For example, if I click on a recently-built bsnes, I can see the WM_NAME (the legacy ASCII name required by the X11 protecol) and _NET_WM_NAME (the more-modern UTF-8 name supported by most apps and window managers) properties, which most window managers will use to display the title bar:

$ xprop | grep WM_NAME
WM_NAME(STRING) = "bsnes v115"
_NET_WM_NAME(UTF8_STRING) = "bsnes v115"

There's another quirky legacy property to be aware of, named WM_CLASS The Xlib Programming Manual describes it like this:

The res_name member contains the application name, and the res_class member contains the application class. Note that the name set in this property may differ from the name set as WM_NAME. That is, WM_NAME specifies what should be displayed in the title bar and, therefore, can contain temporal information (for example, the name of a file currently in an editor's buffer). On the other hand, the name specified as part of WM_CLASS is the formal name of the application that should be used when retrieving the application's resources from the resource database.

That's a confusing description and talks about a bunch of things that fell out of use when Linux desktops coalesced around the Win95 model, so here's an example based on this Firefox Nightly window I have here.

• WM_NAME: "Application name in the Gnome 3 task bar says "hiro" instead of Application::name · Issue Application name in the Gnome 3 task bar says "hiro" instead of Application::name #119 · bsnes-emu/bsnes — Firefox Nightly"
  • that is, the actual title text of the window
• WM_CLASS: "Navigator", "Nightly"
  • that is, this belongs to the application named "Nightly", and of the various windows Nightly can create, this window is of the "Navigator" class.

In this particular instance, "Navigator" is a name that dates back to Netscape 4.x — when Netscape included a browser and an email client and an HTML editor, they advertised themselves as "Navigator", "Mail", or "Composer".

So what does bsnes put in WM_CLASS?

$ xprop | grep WM_CLASS
WM_CLASS(STRING) = "hiro", "Hiro"

It turns out if you grep the bsnes source for WM_CLASS, you'll find a comment on the line where hiro calls gdk_set_program_class()... but it looks like it should only default to "hiro" if the application name is not already set. I'm not sure why it isn't taking effect, but I bet you could set a breakpoint on that line, get a traceback, and find out.