bug#49505: 28.0.50; Multiple launchers in GNOME

[Po Lu]

Tim Ruffing <public@timruffing.de> writes:

> We currently offer two .desktop files both specifying *the same*
> StartupWMClass=Emacs. This means that desktop environments can't match
> windows to applications. When my GNOME sees a windows with WMClass
> "Emacs", it assigns it arbitrarily to emacs.desktop ("Emacs") and not
> emacsclient.desktop ("Emacs (Client)") because there's no unique match.
> That means that when I click the "Emacs (Client)" icon in my dash, a
> window is created but GNOME assumes it belongs to "Emacs", creating
> another icon in my dash representing the "Emacs" window. This is wrong
> and very inconvenient.
>
> There are two ways that can be fixed, either we should have only a
> single application (i.e., .desktop file) or we should make sure that
> windows from emacs and emacsclient can be distinguished based on their
> wmclass:

I would prefer to only have a single desktop file.

> 2. Keep the .desktop files separate, and use separate wmclasses for
> daemon and non-daemon mode
>
> This has also been attempted in
> 1a845a672dc73c8e98e6cb9bb734616e168e60ba by changing argv[0] but this
> was reverted by f355f32e69b1389f7d51b8a50c0a9c064dc2cb32 because
> changing argv[0] is not a great idea. But we could change wmclass
> differently, just by calling gtk_init() with a different string
> depending on whether we're in daemon mode or not.

Not a good idea.  Besides, the Emacs server can also be started inside a
running session, so that wouldn't work perfectly either.

We can have fine-grained control over WM_CLASS (despite whatever the
toolkit does), since Emacs can use X Windows requests to directly set
the WM_CLASS property, but changing that for individual frames based on
how they were created sounds excessive to me.