Conversation
|
Can one of the admins verify this patch?
|
|
This seems weird. The majority of desktop files don't specify StartupWMClass, so with this change almost everyone will. The spec says: 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? |
|
I'm not sure if it's f-b's job to integrate apps with mismatched IDs to the DE. The rename-* properties are the bare minimum, being done to let flatpak export them and are basically an interim solution until apps fix their desktop file names and appids etc. Also afaik this will only work on X11 |
This is just a heuristic but it seems to be usually correct.