Linux desktop integration: Fill StartupWMClass in .desktop menu entries

[Eike Hein]

Hi,

I maintain the taskbar in Plasma 5 and would like to poke folks about a
desktop integration pain point we (and our friends at other DEs) face
with apps run via wine.

Here's the relevant ticket: https://bugs.winehq.org/show_bug.cgi?id=32699

Let me give some broader context on this. Modern DEs have a swath of UX
going on that relies on being able to identify the application owning a
particular window in the windowing system. "Identify the application" in
practice means "map the window to a .desktop file installed in the menu
file system". We want to do this because:

a) Many a taskbar/dock-like UI tries to form a smooth life cycle across
"launcher button", "startup notification" and "window button(s)". For
each of those we need to work out the app they are associated with to be
able to match them up. If it fails, ugly things like co-existing task
buttons or missing startup throbbers and similar happen.

b) UI these days tends to prefer to load assets such as app icons via
the values defined in .desktop files instead of using the window icon,
to ensure consistent results (apps may load icon assets differently from
the shell, leading to asset quality issues, inconsistent theming, the
icon changing between the lifecycle states mentioned in 'a', etc.) Plus
the Wayland windowing system we're all migrating towards currently
doesn'ㅅ have window icons.

c) DEs do things like track app starts/quits for things like "Most used
apps" launcher lists.

To match a window to a .desktop file we rely on window and process metadata.

On X11, there's the WM_CLASS window property:

https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS

Ideally, the second part of a X11 window's WM_CLASS matches the name of
a .desktop file installed on the system. Failing that, it matches the
value of StartupWMClass in that .desktop file (this is the key part I'll
get back to soon).

Here's some more documentation by our friends at Gnome on this standard
scheme:

https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased

(Look for WM_CLASS / StartupWMClass.)

In practice, we pull many other tricks to cope with broken meta data. We
try to match things by names, we grab process command lines from /proc
and check them against Exec keys in .desktop files in complicated ways,
... it's a multi-page heuristic, and other DEs (Unity via bamf, Gnome
Shell via iirc ShellWindowTracker) have equivalent code. Something Gnome
does that we don't do (because I think it's brittle) is to store the
name of the .desktop file an app was launched with as a private window
hint on the next window that comes up (which then doesn't work when the
app was launched from CLI instead of shell UI).

None of these things currently allow us to handle wine very well. As of
now (perhaps thanks to the patch mentioned in the linked ticket), wine
sets WM_CLASS to the executable name of the app, e.g. "Notepad.exe". But
the .desktop files it generates don't match this by name, and they don't
contain a StartupWMClass key. The process command line is the
Windows-like path to the .exe, which we also can't easily match up to
the complicated Exec values in wine's .desktop files.

(Aside: On Wayland, there's a more modern version of this: Windows have
an appid property, which should be set to a .desktop file name. I don't
know what the status of Wayland support in wine is -- currently the wine
clients we encounter run over Xwayland, so we're back to WM_CLASS. We
hope wine will set this property correctly when the time comes, or we're
happy to work with you guys to find a way to support wine.)

Long story short ... could this be picked up? The goal must be to have
either .desktop file names or their StartupWMClass values match whatever
is set as WM_CLASS. Currently, the easiest fix would be to set
StartupWMClass to the executable name set as WM_CLASS. I assume the
.desktop file generator has access to this, as the .lnk file referred to
by Exec should presumably contain the name of the executable to be launched.


Cheers,
Eike

[Vincent Povirk]

It can be more complicated than that, but setting StartupWMClass in
that way would handle this correctly assuming:
 * A .lnk for the executable, and thus a desktop file, already exists.
 * The .lnk file points directly to the executable, and not to a shell
extension or non-executable file.
 * The executable has a unique base filename that only exists in one prefix.
 * There aren't multiple lnk files for the same executable, such as
one in the desktop and one in the start menu. (Are you able to handle
multiple matching .desktop files? This seems like it'd be a common
situation.)
 * The executable does not make use of any modern (>=win7) API's or
attributes in the .lnk file to specify the application a window
belongs to. An example of this would be an interpreter like
python.exe, for which the "application" is the python script being
executed.

So, this would be an improvement, and I see no reason it couldn't be
done, but I just want to point out that there are a lot of other cases
that Windows is able to handle, and Wine could theoretically handle
after more work and cooperation, including pinning programs for which
no shortcut exists (yet).

[Eike Hein]

On April 22, 2017 9:34:36 AM GMT+09:00, Vincent Povirk <madewokherd(a)gmail.com> wrote:
> So, this would be an improvement, and I see no reason it couldn't be
> done, but I just want to point out that there are a lot of other cases
> that Windows is able to handle, and Wine could theoretically handle
> after more work and cooperation, including pinning programs for which
> no shortcut exists (yet).

Oh yeah I expected that - in this area there's always One More Case, and it comes down to trying to handle more and more of them to lift up the user experience over time.

I'd really like it if we could start with this to address the common case we're seeing in user bug reports (in both Plasma and the other DEs), and beyond that we can try to form a working relationship to address additional cases later. I've worked with some wine/CodeWeavers folks on similar integration issues in the past actually, but it's been ages and I lost all track of who was involved. It would be great to take that up again.
> From our POV wine is something pretty unusual that behaves in quirky ways ... but because it's doing something valid and interesting usecase-wise it's also a good thing to look at to make sure specs and code cover that usecase. Many of our users do rely on wine, especially in professional deployments.

Do you see yourself taking a stab at writing a patch for this? I could try, but I lack the sort of broader context knowledge you just demonstrated, plus I don't know the wine codebase. What I can do super easily is test and serve as a general contact point for Linux shell people :)


Cheers,
Eike