Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match

[Michael Albinus]

Corwin Brust <address@hidden> writes:

Hi Corwin,

> I'm sick in bed today and writing from my phone.  What's your excuse? ;)

No excuse, I'm on holidays this week :-)

I wish you the best for recovery!

>> In my experience, D-Bus on MS Windows isn't used so much. You cannot
>> expect it running for MS Windows users of Emacs in general.
>
> As you point out there is little likelihood we will implement enough
> of DBUS to create excitement among windows users inspire it's
> popularity for use outside Emacs.   Moreover, I think neither of us is
> motivated to do anything like a proper DBUS implementation that lives
> outside Emacs.  I wasn't really thinking about trying to do that,
> although it would be cool to help that effort along somehow.

And there's also another problem. D-Bus is just infrastructure,
providing interprocess communication means. On GNU/Linux, we use D-Bus
to speak with the service "org.freedesktop.Notifications", which offers
the API for desktop notifications. I haven't heard of a similar D-Bus
service implementation for MS Windows.

> Would it make sense to create am elisp package that installs advice on
> the functions that (for most users) invoke DBUS?  It seems like,
> especially, this could be the easiest way to get windows notification
> center support into core quickly.

I would oppose such an approach. We shouldn't fake D-Bus on MS Windows,
when it isn't D-Bus.

Instead of, we might try to implement the notifications.el interface
with other means but D-Bus on MS Windows.

But even this wouldn't be necessary, if we have alert.el as general
notification interface for Emacs. We could add just another package
which implements windows notification center, and integrate it into
alert.el like the other existing alert styles.

For MS Windows specific implementation options, I cannot speak seriously
about. However, ...

> This would look rather like the DBUS wrapper in C for GNU/Linus, Mac,
> and Cygwin but wrapping (probably) the Windows Community Toolkit.
> This would definitely allow us to properly associate Emacs as the
> originating process and probably opens the door to let users
> create/manage GUIDs on the fly, which can to differentiate toasts as
> from different logical processes within Emacs and/or different users
> of Emacs.

... this doesn't sound bad in my ears.

Best regards, Michael.