Window Tracker shouldn't match windows by sandboxed ID before checking WM_CLASS
As mentioned in 0c22a21a (comment 98927), there's an issue with how the shell is currently matching Windows to Applications, when those applications are sadnboxed (flatpaks, or snaps):
The call to get_app_from_sandboxed_app_id()
is placed before the one to get_app_from_window_wmclass()
in get_app_for_window()
, meaning that any StartupWMClass
key included in the .desktop
files for the application are ignored, since the sandboxed ID will return a valid value and get_app_for_window()
will return early.
This causes an issue with sandboxed applications that install multiple files, as it's the case of LibreOffice, which is now packaged as a flatpak, that won't ever use the right .desktop
file
for the different applications shipped with the suite (e.g. Calc, Writer...):
- Click on the LibreOffice Writer icon from the apps view --> The shell will launch the application creating a
ShellApp
instance during startup associated to theorg.libreoffice.LibreOffice-writer.desktop
file. - Once the startup process finishes, the main window from LO Writer is presented and the shell attempts to assign it a
ShellApp
to track it, but since theget_app_from_flatpak_id()
returns a valid value (org.libreoffice.LibreOffice
), a newShellApp
instance will be created, associated toorg.libreoffice.LibreOffice.desktop
, instead of usingorg.libreoffice.LibreOffice-writer.desktop
.
Some implications of this are:
- The Alt-Tab switcher will show the generic LO icon, not Writer's one
- All LO apps (Writer, Calc, Draw...) will be grouped under the same
ShellApp
I've been running some tests and I think moving the call to get_app_from_flatpak_id()
lower in that function right between get_app_from_window_wmclass()
and get_app_from_window_pid()
might work, hopefully without causing the problem mentioned in the commit message of 0c22a21a, related to unrelated apps becoming grouped because of the sandboxed PID matching PIDs outside the sandbox.