GNU bug report logs - #49505
28.0.50; Multiple launchers in GNOME

Previous Next

Full log

Message #70 received at 49505 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Tim Ruffing <public <at> timruffing.de>
Cc: 49505 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti <at> inventati.org>,
 Peter Oliver <p.d.oliver <at> mavit.org.uk>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#49505: 28.0.50; Multiple launchers in GNOME
Date: Tue, 24 May 2022 21:39:16 +0800

Tim Ruffing <public <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.