From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Ruffing Newsgroups: gmane.emacs.bugs Subject: bug#49505: 28.0.50; Multiple launchers in GNOME Date: Tue, 24 May 2022 14:33:17 +0200 Message-ID: <8e5d9ea72584f981124ade5c69ec7162751723fe.camel@timruffing.de> References: <87sg0mnn9o.fsf@gnus.org> <2b12a676-2e15-1094-6525-4d11268912d@froglet.home.mavit.org.uk> <9245be25-3962-0b25-1c04-dabb77b6e9d7@inventati.org> <16370f3-a2a-9ce6-3af5-396da88a4dc8@froglet.home.mavit.org.uk> <87mtnio2qt.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14760"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49505@debbugs.gnu.org To: Manuel Uberti , Lars Ingebrigtsen , Peter Oliver Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 24 14:52:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntU1B-0003b4-D8 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 May 2022 14:52:09 +0200 Original-Received: from localhost ([::1]:43700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntU1A-0006gE-92 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 May 2022 08:52:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntTjf-00034d-Qm for bug-gnu-emacs@gnu.org; Tue, 24 May 2022 08:34:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57325) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ntTjf-0002y5-HB for bug-gnu-emacs@gnu.org; Tue, 24 May 2022 08:34:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ntTje-0004S3-DS for bug-gnu-emacs@gnu.org; Tue, 24 May 2022 08:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tim Ruffing Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 May 2022 12:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49505 X-GNU-PR-Package: emacs Original-Received: via spool by 49505-submit@debbugs.gnu.org id=B49505.165339561217075 (code B ref 49505); Tue, 24 May 2022 12:34:02 +0000 Original-Received: (at 49505) by debbugs.gnu.org; 24 May 2022 12:33:32 +0000 Original-Received: from localhost ([127.0.0.1]:51222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntTj9-0004RK-Jx for submit@debbugs.gnu.org; Tue, 24 May 2022 08:33:32 -0400 Original-Received: from mout-p-201.mailbox.org ([80.241.56.171]:37284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntTj5-0004R2-VL for 49505@debbugs.gnu.org; Tue, 24 May 2022 08:33:29 -0400 Original-Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4L6tsC3g67z9sV8; Tue, 24 May 2022 14:33:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timruffing.de; s=MBO0001; t=1653395599; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lzncMZn7rbiofPCUhOr3PwKInAV4kCJcwPZb6L0PwuA=; b=m3oI49+2NEvHWIMFtTS05uiZfl8k8BAMNKmByypnl25Fn4syAz/tpsUsELJ1mR+I7+oQXG kR7tKzQ2X6RZ0KHTG3VFIFLbIOi1rl6soKwMobuykbg+XYsZJdp5qfSUHnVFg+Dx4h2fvi lAkRDGXuOUQ6Xame241Qjf4nmdcrTmcC+REzWPA1v3qdlifFprEpS/32QH5SRW9jV/1a+T RWR9D1o+RWHwDEiJ4E7mEVnBczQ4fSeu1YqaXpwkmi0iI0JDgwxhSMeumBo/WpEqd8l6i+ nAdvaHlB39NdtWohNOrjEX84j9Z8BloAAb9HCxEkZ1Sv78V3/ep7GY2kuKrgTQ== In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233001 Archived-At: Hi, this is not yet solved. I tried to investigate it and it's quite a rabbit hole: So GNOME (and I suppose the same for KDE?) can't track "windows" started by emacsclient properly, which is the problem as initially reported by Manuel here. This problem still exists and I encounter it, too:=C2=A0 We currently offer two .desktop files both specifying *the same* StartupWMClass=3DEmacs. 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: ---- 1. Unify the .desktop files I know this has been tried already and was reverted because that particular approach has forced users into using the daemon, which I fully agree was not a good idea. What we could do instead is to have have a single emacs.desktop that simply does the following: Try to connect to daemon and create a new frame, if there's no daemon, just launch a new instance (e.g., using emacsclient -a emacs). This will get an automatic "New Window" action in the context menu (at least in GNOME, need to check for others), because if you left-click again, you'll simply switch to an existing window. That's very simple, and it always will manage to bring up emacs, so it's "safe" for the average user. It won't confuse new users because who don't know whether they should launch "Emacs" or "Emacs (Client)". And it leaves decision of using the daemon to the user, who can enable or disable it using systemctl (or other ways) on normal desktops. If didn't opt in to run a daemon, you won't even notice that emacs has a daemon mode. Advanced users who need something special, e.g, they want to bring up a new non-daemon instance even though a daemon is running, can still customize and create their own .desktop files or shortcuts. This is nothing we should optimize for. The only drawback of this approach is that ideally "New Window" would bring up a just a new frame but this will work only in daemon mode. In non-daemon mode, you'll get a new instance. But I'm not sure if this could be solved quickly because I'm not sure if there's a way to ask a non-daemon emacs to create a new frame. I think in the long-term we could for example use D-Bus activation [1] and make non-daemon emacs expose a dbus service that can create frames. But that's a larger project. Ideally there would be a "semi-daemon" mode, which is in between the daemon mode and the normal mode: The first invocation launches a daemon, further invocations (e.g., using emacsclient, or dbus) would just create new frames BUT if you close the last frame, no daemon will stay around. This would exactly match the behavior of other desktop applications. ---- 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. I think that would also work. This comes with a risk of breaking some user scripts / config that rely on the wmclass instance name (similar to how some things relied on matching argv[0]) but I don't think that'll be a big deal. ---- In the end, I'd favor the first approach. A single .desktop will offer the same functionality as we have currently, will confuse users less than the currently separate files, and is on the right track for an better solution in the long-term. Moreover, the first approach can probably simplify the mess a little bit because we should be able to drop "StartupWMClass" entirely, which would probably avoid some more problems [4].=20 What do you think? I'd be willing to create a patch for either of the approaches but I first wanted to check here because this seems a complex and controversial topic. Tim PS: An entirely different issue is "startup notification" with the emacsclient, i.e., the desktop environment has noticed that the app has started up and can turn off the "waiting spinner" for example. This needs some passing around of startup ids, which we currently don't do via emacsclient. But that's far less annoying in practice. I can create a separate bug for that. [1] https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry= -spec-latest.html#dbus [2] Currently on GNOME on Wayland, the match based on StartupWMClass doesn't work due to the different capitalization in the Wayland appid (somewhat equivalent to WM_CLASS on X), which is "emacs". Setting StartupWMClass is not necessary AFAIU, and desktop environments will simply match based on the filename of the .desktop file and case doesn't seem to matter here. The actual logic is pretty ugly (GNOME [3], KDE [4]) and we so we should test this. One of the problems here is that WM_CLASS consists of two strings in fact, the "name" and the "class". In our case that's "emacs" and "Emacs", and the freedesktop spec for .desktop doesn't specify which one should be taken... [3] https://github.com/GNOME/gnome-shell/blob/main/src/shell-window-tracker= .c#L198 [4] https://github.com/KDE/plasma-workspace/blob/070009a5cb9387596230c60081= 02a288f7972ba5/libtaskmanager/tasktools.cpp#L195