bug#49504: Server support for Freedesktop.org startup notification

bug#49504: Server support for Freedesktop.org startup notification

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

For a desktop environment, it’s helpful to know which execs caused which windows to be opened.  One way of doing this is with the Freedesktop.org startup notification protocol, https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt.

We currently partially support this protocol in GTK builds, because GTK handles it for us automatically.  However, GTK can only automatically handle the simple case where emacs is launched and displays a window itself.

To support emacsclient, where the execed process is not necessarily an ancestor of the process displaying the window, as I understand it we’d need to do the following:

- Pass the value of the DESKTOP_STARTUP_ID environment variable from emacsclient to emacs.
- When opening a new frame at the request of emacsclient, call C function gtk_window_set_startup_id with the value from DESKTOP_STARTUP_ID.

-- 
Peter Oliver

bug#49504: Server support for Freedesktop.org startup notification

[Eli Zaretskii]

> Date: Sat, 10 Jul 2021 12:43:39 +0100 (BST)
> From: Peter Oliver <p.d.oliver@mavit.org.uk>
> 
> For a desktop environment, it’s helpful to know which execs caused which windows to be opened.  One way of doing this is with the Freedesktop.org startup notification protocol, https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt.
> 
> We currently partially support this protocol in GTK builds, because GTK handles it for us automatically.  However, GTK can only automatically handle the simple case where emacs is launched and displays a window itself.
> 
> To support emacsclient, where the execed process is not necessarily an ancestor of the process displaying the window, as I understand it we’d need to do the following:

You want to make the Emacs frame displayed due to an emacsclient
request show emacsclient as its "exec"?  But then what happens if the
user uses that frame for displaying other windows and buffers, which
have nothing to do with the original emacsclient request?

bug#49504: Acknowledgement (Server support for Freedesktop.org startup notification)

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 125 bytes --]

In the meantime, here’s a patch which unadvertises startup notification support from emacsclient.desktop.

-- 
Peter Oliver

[-- Attachment #2: Type: text/plain, Size: 1772 bytes --]

From a8567bf18abe95d1d39209496ca488c76523cde3 Mon Sep 17 00:00:00 2001
From: Peter Oliver <git@mavit.org.uk>
Date: Sat, 10 Jul 2021 12:10:08 +0100
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20claim=20support=20for=20startup?=
 =?UTF-8?q?=20notification=20for=20emacsclient?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

GTK gives us free support for Freedesktop.org startup notification,
but only in the simple case that we are displaying a window for the
first time from a process that has been passed the appropriate
DESKTOP_STARTUP_ID environment variable by the launcher.  With
emacsclient, that’s often not the case.

* etc/emacsclient.desktop: Don’t advertise StartupNotify support.
---
 Makefile.in             | 1 -
 etc/emacsclient.desktop | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 97d954b6ce..5c58e45717 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -738,7 +738,6 @@ install-etc:
 	client_name=`echo emacsclient | sed '$(TRANSFORM)'`${EXEEXT}; \
 	sed -e "/^Exec=emacsclient/ s|emacsclient|${bindir}/$${client_name}|" \
 	  -e "/^Icon=emacs/ s/emacs/${EMACS_NAME}/" \
-	  $(USE_STARTUP_NOTIFICATION_SED_CMD) \
 	  ${srcdir}/etc/emacsclient.desktop > $${tmp}; \
 	${INSTALL_DATA} $${tmp} "$(DESTDIR)${desktopdir}/$${client_name}.desktop"; \
 	rm -f $${tmp}
diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
index cd45463093..c3cacb9029 100644
--- a/etc/emacsclient.desktop
+++ b/etc/emacsclient.desktop
@@ -8,7 +8,6 @@ Icon=emacs
 Type=Application
 Terminal=false
 Categories=Development;TextEditor;
-StartupNotify=true
 StartupWMClass=Emacs
 Keywords=Text;Editor;
 Actions=new-window;new-instance;
-- 
2.31.1

bug#49504: Server support for Freedesktop.org startup notification

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Sat, 10 Jul 2021, Eli Zaretskii wrote:

> You want to make the Emacs frame displayed due to an emacsclient
> request show emacsclient as its "exec"?  But then what happens if the
> user uses that frame for displaying other windows and buffers, which
> have nothing to do with the original emacsclient request?

Here’s an example of a feature enabled by the startup notification protocol.

When a user clicks on an icon for an application in a desktop’s launcher, the launcher will provide feedback to the user that something is happening, perhaps by changing the pointer to the “busy” indicator.  That feedback will be cleared once the application displays a window.  For the launcher to know when to clear the feedback, it needs to know that a particular window is associated with a particular application launch.

So, in the case you describe, where the user goes on to display other buffers, nothing happens, and that’s fine.

-- 
Peter Oliver

bug#49504: Server support for Freedesktop.org startup notification

[Eli Zaretskii]

> Date: Sat, 10 Jul 2021 13:56:11 +0100 (BST)
> From: Peter Oliver <p.d.oliver@mavit.org.uk>
> cc: 49504@debbugs.gnu.org
> 
> > You want to make the Emacs frame displayed due to an emacsclient
> > request show emacsclient as its "exec"?  But then what happens if the
> > user uses that frame for displaying other windows and buffers, which
> > have nothing to do with the original emacsclient request?
> 
> Here’s an example of a feature enabled by the startup notification protocol.
> 
> When a user clicks on an icon for an application in a desktop’s launcher, the launcher will provide feedback to the user that something is happening, perhaps by changing the pointer to the “busy” indicator.  That feedback will be cleared once the application displays a window.  For the launcher to know when to clear the feedback, it needs to know that a particular window is associated with a particular application launch.
> 
> So, in the case you describe, where the user goes on to display other buffers, nothing happens, and that’s fine.

But that was only an example, right?  I asked a more general question.

Emacs is different from many, if not most, applications in this
regard.  For example, it can start any number of windows from the same
"launch".  I'm asking whether we are going to use desktop features
that don't really fit Emacs.