GNU bug report logs - #49504
Server support for Freedesktop.org startup notification

Previous Next

Package: emacs;

Reported by: Peter Oliver <p.d.oliver <at> mavit.org.uk>

Date: Sat, 10 Jul 2021 11:44:01 UTC

Severity: normal

To reply to this bug, email your comments to 49504 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#49504; Package emacs. (Sat, 10 Jul 2021 11:44:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Oliver <p.d.oliver <at> mavit.org.uk>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 10 Jul 2021 11:44:02 GMT) Full text and rfc822 format available.

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

From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
To: bug-gnu-emacs <at> gnu.org
Subject: Server support for Freedesktop.org startup notification
Date: Sat, 10 Jul 2021 12:43:39 +0100 (BST)
[Message part 1 (text/plain, inline)]
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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49504; Package emacs. (Sat, 10 Jul 2021 12:39:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Oliver <p.d.oliver <at> mavit.org.uk>
Cc: 49504 <at> debbugs.gnu.org
Subject: Re: bug#49504: Server support for Freedesktop.org startup notification
Date: Sat, 10 Jul 2021 15:37:55 +0300
> Date: Sat, 10 Jul 2021 12:43:39 +0100 (BST)
> From: Peter Oliver <p.d.oliver <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49504; Package emacs. (Sat, 10 Jul 2021 12:43:02 GMT) Full text and rfc822 format available.

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

From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
To: 49504 <at> debbugs.gnu.org
Subject: Re: bug#49504: Acknowledgement (Server support for Freedesktop.org
 startup notification)
Date: Sat, 10 Jul 2021 13:41:56 +0100 (BST)
[Message part 1 (text/plain, inline)]
In the meantime, here’s a patch which unadvertises startup notification support from emacsclient.desktop.

-- 
Peter Oliver
[0001-Don-t-claim-support-for-startup-notification-for-ema.patch (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49504; Package emacs. (Sat, 10 Jul 2021 12:57:02 GMT) Full text and rfc822 format available.

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

From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49504 <at> debbugs.gnu.org
Subject: Re: bug#49504: Server support for Freedesktop.org startup notification
Date: Sat, 10 Jul 2021 13:56:11 +0100 (BST)
[Message part 1 (text/plain, inline)]
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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49504; Package emacs. (Sat, 10 Jul 2021 14:31:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Oliver <p.d.oliver <at> mavit.org.uk>
Cc: 49504 <at> debbugs.gnu.org
Subject: Re: bug#49504: Server support for Freedesktop.org startup notification
Date: Sat, 10 Jul 2021 17:30:21 +0300
> Date: Sat, 10 Jul 2021 13:56:11 +0100 (BST)
> From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> cc: 49504 <at> 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.




This bug report was last modified 2 years and 262 days ago.

Previous Next


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