Set desktop file StartupWMClass if renamed

[TingPing]

This is just a heuristic but it seems to be usually correct.

[rh-atomic-bot]

Can one of the admins verify this patch?
I understand the following commands:

• bot, add author to whitelist
• bot, test pull request
• bot, test pull request once

[alexlarsson]

This seems weird. The majority of desktop files don't specify StartupWMClass, so with this change almost everyone will. The spec says:

Desktop entry spec extensions
===

StartupNotify=BOOLEAN

  If true, it is KNOWN that the application will send a "remove"
  message when started with the DESKTOP_LAUNCH_ID environment variable
  set.

StartupWMClass=STRING

  If true, it is KNOWN that the application will map at least one
  window with the given string as its WM class or WM name hint.

The ones that set StartupNotify=true rely on callers using the DESKTOP_LAUNCH_ID env var, and there is no need to set StartupWMClass. If StartupWMClass is set then we should not mess with it.

So, the two remaining cases are when StartupWMClass is unset and StartupNotify is false or unset.

The specs mention nothing about default values for StartupWMClass, and I understand that, because it seems risky to assume them, because if you get the wrong value or the app didn't set a WMClass then the startup spinner will go on forever. If StartupWMClass was not set, we just wouldn't use startup notification, which seems like a better default.

Do you have a reference to any code that relies on the WMClass matching the desktop file name?

[TingPing]

https://github.com/GNOME/gnome-shell/blob/5136369c188a9cad01915714a5e3819d76f0824c/src/shell-app-system.c#L284-L333

https://github.com/GNOME/gnome-shell/blob/f9569912df0e05a101375f04f4bb243f2c778a83/src/shell-window-tracker.c#L192-L200