~abcdw/rde-discuss

1

Move emacs-ednc-related code in contrib ?

Details
Message ID
<875xxtzzkd.fsf@ngraves.fr>
DKIM signature
missing
Download raw message
Hi RDE, 

We currently have two different notification daemons available. ednc
provides a deamon that is native to emacs, swaynotificationcenter
provides another one that is independent from emacs.

In the soon-to-merge emacs background server, we use
notify-send/libnotify to send notifications when the emacs-daemon is
starting but not fully started. This would advocate for a clear
recommandation for a notification daemon that is independent from emacs.

WDYT about moving the emacs-ednc feature to contrib after this?

I'll also try to rewrite the only place where emacs-ednc is used
(goimapnotify) to make the notification independent from the emacs, this
should in principle work since ednc claims to comply with the
freedesktop.org specification.

-- 
Best regards,
Nicolas Graves

Re: Move emacs-ednc-related code in contrib ?

Details
Message ID
<874jdav6mu.fsf@trop.in>
In-Reply-To
<875xxtzzkd.fsf@ngraves.fr> (view parent)
DKIM signature
pass
Download raw message
On 2024-03-10 19:55, Nicolas Graves wrote:

> Hi RDE, 
>
> We currently have two different notification daemons available. ednc
> provides a deamon that is native to emacs, swaynotificationcenter
> provides another one that is independent from emacs.
>
> In the soon-to-merge emacs background server, we use
> notify-send/libnotify to send notifications when the emacs-daemon is
> starting but not fully started. This would advocate for a clear
> recommandation for a notification daemon that is independent from emacs.
>
> WDYT about moving the emacs-ednc feature to contrib after this?
>
> I'll also try to rewrite the only place where emacs-ednc is used
> (goimapnotify) to make the notification independent from the emacs, this
> should in principle work since ednc claims to comply with the
> freedesktop.org specification.

I agree.

Also, I think that it's a good idea to rely on more robust non-emacs
solutions, as I think we will be gradually migrating tools to
compositor/window manager level.  app-launcher, emacs completion
interface, picking tab in a browser or window in your desktop
environment would be implemented by separate program (probably a guile
program, which will be a part of compositor).  This direction will make
it possible to integrate desktop apps much better between each other,
unify keybindings, interfaces and interaction patterns.  Probably a bit
distant future, but still seems like a reasonable direction to keep in
mind.

-- 
Best regards,
Andrew Tropin
Reply to thread Export thread (mbox)