GNU bug report logs -
#49504
Server support for Freedesktop.org startup notification
Previous Next
To reply to this bug, email your comments to 49504 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
[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):
> 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):
[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):
[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):
> 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 3 years and 192 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.