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

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

[Michael Albinus]

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

Grrr. Now I have forgotten emacs-devel in the list of addressees.


[-- Attachment #2: Type: message/rfc822, Size: 9021 bytes --]

From: Michael Albinus <michael.albinus@gmx.de>
To: Corwin Brust <corwin@bru.st>
Cc: rms@gnu.org,  gnu-emacs-sources@gnu.org
Subject: Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match
Date: Tue, 03 Mar 2020 20:06:45 +0100

Corwin Brust <corwin@bru.st> writes:

> I inadvertently hit "Reply" instead of "Reply-All".    My apologies
> and for now top-posting.

No reason to despair, it happens to us all the time. I'll also change
the ML from gnu-emacs-sources@gnu.org to emacs-devel@gnu.org, where it
belongs to.

Full-quoting for the people of that ML.

>> On Tue, Mar 3, 2020 at 9:32 AM Michael Albinus <michael.albinus@gmx.de> wrote:
>> > > I would love to see core Emacs (and/or a popular notifications
>> > > modules) support notifications for all platforms natively.  To that
>> > > end, I'm absolutely fine with folding the 15-30 or so important sloc
>> > > from this solution into an existing package, or more than one of them
>> > > if that makes sense.   That said, I'm leery of offering up brand-new
>> > > feature, lightly tested by the author, to a stable package a
>> > > potentially much larger portion of the user base depends on.
>> > > Especially in as much as it would bring along a system dependency in
>> > > the form of the Burnt-Toast PowerShell module.   Maybe there's a way
>> > > to use the advice system to install globally but only affect Windows
>> > > users and implicitly take settings meant for DBUS setup?
>> >
>> > erc-desktop-notifications.el, part of the ERC subsystem, supports
>> > GNU/Linux notifications only if I'm not misguided.
>>
>> That's what I see from the 27.0.50 GNU binary dist.  I didn't poke
>> around in master but that's what I expect to see there too.
>>
>> I dropped a quick note on IRC where I've chatted some with the ERC
>> maintainer "bandali" to feel him (and other users) out for an appetite
>> for putting win32 special case logic into this one.  At a minimum, I
>> suspect we need at least one additional shell process/call for all
>> users of Windows native (not cyg) binaries, to automatically detect
>> the presence of the BurntToast PowerShell module, which my efforts so
>> far rely on.  In theory, this could be changed to depend directly on
>> the Windows Community Toolkit project, but more on this presently.

That's not a problem. You will send this process call only if
system-type is equal to 'windows-nt, and you will send this only once,
keeping the result during the Emacs session.

>> > There is alert.el on MELPA, which supports different platforms
>> > (including GNU/Linux via D-Bus). I believe, MS Windows/Powershell is not
>> > supported yet (but I'm not sure). Maybe your Powershell related code
>> > could be plugged in.
>>
>> This looks like the best bet.  I will work on this, starting with
>> asking if adding special casing for Windows users is of interest and
>> whether this solution seems robust enough.  I really don't see a way
>> out of opening/using a shell process to query PowerShell for
>> availability either of Burnt-Toast or of the UNC framework on which
>> /it/ depends, so I'll likely mention that potential downside.

Yep. See above.

>> I'm using ercn which hasn't been updated for several years.  I've no
>> trouble switching to setup to use alert.el; I'll do that presently.
>> Incidentally, and IIUC adding support for burnt-toast to ercn just
>> looks like publishing a new package that depends on ercn and defines
>> the setup more or less as I've shown in the readme for the subject
>> program, notwithstanding it expects the minor mode thus generated to
>> be called erc-notifications-mode vs erc-burnt-toast-mode as I
>> currently have done.

I've seen ercn in the packages list, but I don't know how much it is
used. And there is also erc-nick-notify on MARMELADE, for which I
haven't an opinion either.

IIRC, there was a discussion some years ago to harmonize all of this,
and to bring it into the GNU ELPA repository. I don't remember the
result of this discussion.

>> > There is also erc-alert.el at
>> > <https://github.com/jwiegley/dot-emacs/blob/master/lisp/erc-alert.el>,
>> > which uses alert.el for ERC notifications. Since this package is not
>> > available on GNU ELPA or MELPA, I don't know its status.
>> >
>> > Maybe one could try to merge all of them together, somehow. alert.el and
>> > erc-alert.el are written by John Wiegley, the Emacs maintainer. He will
>> > know much better the status and future plans.
>>
>> Since I'll be reaching out to John (probably via feature request to
>> the alert.el project?) I'll have a chance to ask.
>>
>> To the extend John would appreciate the support, I can also offer to
>> help with maintenance, especially of things I would have to take a
>> chance at breaking to smoothly integrate support for Windows users.
>> Any chance you'd want to be a phone-a-friend if John does ask for
>> support maintaining alert.el &ct in considering taking this feature
>> in/on?

I will try to help you. However, you shall know that I don't run MS
Windows myself, so I cannot tell too much about the details of your
implementation.

>> Also, is Eli the Emacs maintainer?  I thought John Wiegly was package
>> maintainer or more to do with Elpa somehow.

Both John and Eli are the Emacs maintainers.

>> I'm kinda... "new" if
>> that isn't showing yet.  I used Emacs seriously also a couple of
>> decades back but have only started trying to make elisp work for me
>> these past several months.  I subscribed to several mailing lists but
>> I won't pretend to understand all that much of what I'm reading.

I'm contributing to Emacs 15+ years, but I could say the same :-)

>> Coming back to Windows support relying on Burnt-Toast vs building
>> something to use the Windows Community Toolkit (for PowerShell)
>> directly vs writing a custom C# assembly or otherwise messing with the
>> Emacs build, vs etc., and I find that this needs more thought.
>>
>> I've no trouble sharing my Burnt-Toast based solution with any package
>> maintainer who feels it may add value.  Without question, I can
>> implement more of WIndows Notification Center either as exposed by
>> Burnt-Toast or with some custom PowerShell or C#.  And, if we're
>> talking about C# then we can also think about bypassing the toolkit's
>> API and working directly with Windows.  I think I can see where it
>> /might/ make sense to more fully implement the API from the Windows
>> Community Toolkit to/for Emacs, but..  maybe as a DBUS stint?

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.

However, I would expect a general notification mechanism on MS Windows
would be of use in Emacs. But Eli is definitely much better to say
what's good on that platform.

>> In looking at erc-desktop-notifications.el I bumped into the core DBUS
>> functionality that Emacs ships with.  This, it seems, is too hairy for
>> me.  Worse, the DBUS project page claims "a port is in progress" says
>> little else to wit since 2018.  Considering that Emacs relies already
>> on C code for optionally compiled in DBUS support it seems obvious
>> that what's /really/ wanted here is a drop in DBUS implementation
>> targeting native win32.

If that will be widely supported on MS-Windows: yes. But still in this
case, I believe that using a platform's native API, like the Windows
Notification Center, might be better suited. (Saying this as the guy who
wrote the D-Bus integration initially)

>> What are your thoughts on focusing on a DBUS stint that is maybe
>> native windows code and has the goal of making as much existing Emacs
>> config as possible Just Work(sm) under Windows?  Frankly, bringing
>> Windows to DBUSfeels better from the "Free Software" standpoint than
>> bringing Emacs to Windows, in that it tends to standardize Emacs as a
>> platform rather than potentially cave to vendor-specific features that
>> could create an appetite for Emacs under non-free software.  (Screw
>> that.)  I'd be open to contribute in this area too/instead if my
>> limited and rusty C (and C#) skills or novice Emacs Lisp knowledge or
>> access to proprietary personal and (maybe) enterprise operating
>> environments could be useful but, again and still, I'd be relying on
>> the community to help me find my way.

In general, I agree with you. But I still haven't seen much D-Bus
support on MS Windows. Widespread.

(To be honest, I don't see anything on MS Windows 'cos I don't use
it. This is just what I understand from different mailing lists. I
could be completely wrong.)

>> I can reach out to John in any case since insight into plans for
>> alert.el (and erc-alert.el) are potentially useful in all sorts of
>> cases.

Yes. And again, if we could bring at least alert.el to GNU ELPA, this
would also be a win.

>> Regards warmly returned, Michael!

Best regards, Michael.

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

[Corwin Brust]

I'm sick in bed today and writing from my phone.  What's your excuse? ;)
I'm very pleased to meet you, Michael.  Thanks for another thoughtful reply.

[In fact, I came to the desk to spellcheck on the desktop so I'm
officially out of bed.  I guess I have to check work email now?]

On Tue, Mar 3, 2020, 13:19 Michael Albinus <michael.albinus@gmx.de> wrote:
>
> Grrr. Now I have forgotten emacs-devel in the list of addressees.
>
>
>
>
> ---------- Forwarded message ----------
> From: Michael Albinus <michael.albinus@gmx.de>
> To: Corwin Brust <corwin@bru.st>
> Cc: rms@gnu.org, gnu-emacs-sources@gnu.org
> Bcc:
> Date: Tue, 03 Mar 2020 20:06:45 +0100
> Subject: Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match
> Corwin Brust <corwin@bru.st> writes:
>
> > I inadvertently hit "Reply" instead of "Reply-All".    My apologies
> > and for now top-posting.
>
> No reason to despair, it happens to us all the time. I'll also change
> the ML from gnu-emacs-sources@gnu.org to emacs-devel@gnu.org, where it
> belongs to.
>
> Full-quoting for the people of that ML.


Thanks.  Here I'll do my best to confine to a subject per message.

First, or at any rate here, I'd like to keep ferreting out the ideal scope.

Always assuming neither pick up the thread, so to speak, from this
list. I'll copy in Eli directly in a bit to request papers and clarify
my situation as regards, and I propose we can also copy John
explicitly just prior to opening an issue to/PR for alert.el and given
we don't talk ourselves out of that somehow.

> >> On Tue, Mar 3, 2020 at 9:32 AM Michael Albinus <michael.albinus@gmx.de> wrote:
> >> > > I would love to see core Emacs (and/or a popular notifications
> >> > > modules) support notifications for all platforms natively.  To that
> >> > > end, I'm absolutely fine with folding the 15-30 or so important sloc
> >> > > from this solution into an existing package, or more than one of them
> >> > > if that makes sense.   That said, I'm leery of offering up brand-new
> >> > > feature, lightly tested by the author, to a stable package a
> >> > > potentially much larger portion of the user base depends on.
> >> > > Especially in as much as it would bring along a system dependency in
> >> > > the form of the Burnt-Toast PowerShell module.   Maybe there's a way
> >> > > to use the advice system to install globally but only affect Windows
> >> > > users and implicitly take settings meant for DBUS setup?
> >> >
> >> > erc-desktop-notifications.el, part of the ERC subsystem, supports
> >> > GNU/Linux notifications only if I'm not misguided.
> >>
> >> That's what I see from the 27.0.50 GNU binary dist.  I didn't poke
> >> around in master but that's what I expect to see there too.
> >>
> >> I dropped a quick note on IRC where I've chatted some with the ERC
> >> maintainer "bandali" to feel him (and other users) out for an appetite
> >> for putting win32 special case logic into this one.  At a minimum, I
> >> suspect we need at least one additional shell process/call for all
> >> users of Windows native (not cyg) binaries, to automatically detect
> >> the presence of the BurntToast PowerShell module, which my efforts so
> >> far rely on.  In theory, this could be changed to depend directly on
> >> the Windows Community Toolkit project, but more on this presently.
>
> That's not a problem. You will send this process call only if
> system-type is equal to 'windows-nt, and you will send this only once,
> keeping the result during the Emacs session.


Can do.

> >> > There is alert.el on MELPA, which supports different platforms
> >> > (including GNU/Linux via D-Bus). I believe, MS Windows/Powershell is not
> >> > supported yet (but I'm not sure). Maybe your Powershell related code
> >> > could be plugged in.
> >>
> >> This looks like the best bet.  I will work on this, starting with
> >> asking if adding special casing for Windows users is of interest and
> >> whether this solution seems robust enough.  I really don't see a way
> >> out of opening/using a shell process to query PowerShell for
> >> availability either of Burnt-Toast or of the UNC framework on which
> >> /it/ depends, so I'll likely mention that potential downside.
>
> Yep. See above.


Okay.   I agree this may be pretty easy -always assuming the general
approach is on the road to robust- to support windows notification
center fairly implicitly for alert.el users.   This assumes, as I
currently have done in erc-burnt-toast.el, that windows users can -and
have- successfully navigated installing the PowerShell dependency from
which I took the name:

  Burnt-Toast by Joshua King (MIT) - https://github.com/Windos/BurntToast

But let's come back to this point in the context the onus alternatives
place upon the user vs and considering the potential complicity each
may introduce to the Emacs universe.

Note, however, I can't currently build on Windows and have been
working at it a week or two I'm tending to assume complicating all
that takes some work in justifying and that.  My point here is that
I'm not brushing off.. call it: "Option 1: offer patches for alert.el,
and maybe erc-alert.el, and maybe merge them".    And I assume we may
end up with several answers worthy of some further testing/analysis.

> >> I'm using ercn which hasn't been updated for several years.  I've no
> >> trouble switching to setup to use alert.el; I'll do that presently.
> >> Incidentally, and IIUC adding support for burnt-toast to ercn just
> >> looks like publishing a new package that depends on ercn and defines
> >> the setup more or less as I've shown in the readme for the subject
> >> program, notwithstanding it expects the minor mode thus generated to
> >> be called erc-notifications-mode vs erc-burnt-toast-mode as I
> >> currently have done.
>
> I've seen ercn in the packages list, but I don't know how much it is
> used. And there is also erc-nick-notify on MARMELADE, for which I
> haven't an opinion either.


This too looks easy to patch for use burnt-toast if under native
Windows, module present, etc. and so on.   I can even maybe work on
this first?  I will email Andy and see of he would like to see agree
an extra conditional in the else block that reuses his vars to make a
PowerShell command when it would work.   I can also too what he thinks
should happen for windows users who don't have Burnt-Toast.

>
> IIRC, there was a discussion some years ago to harmonize all of this,
> and to bring it into the GNU ELPA repository. I don't remember the
> result of this discussion.


I feel that.  I think this relates to my fixation with doing a DBUS
stint - core feels like it is (becoming) fairly centralized on DBUS
and I think our goal is bringing capability symmetry to Emacs for
multi-platform and windows only users.  Well, config symmetry would
also be good.

But...

>
> >> > There is also erc-alert.el at
> >> > <https://github.com/jwiegley/dot-emacs/blob/master/lisp/erc-alert.el>,
> >> > which uses alert.el for ERC notifications. Since this package is not
> >> > available on GNU ELPA or MELPA, I don't know its status.
> >> >
> >> > Maybe one could try to merge all of them together, somehow. alert.el and
> >> > erc-alert.el are written by John Wiegley, the Emacs maintainer. He will
> >> > know much better the status and future plans.
> >>
> >> Since I'll be reaching out to John (probably via feature request to
> >> the alert.el project?) I'll have a chance to ask.
> >>
> >> To the extend John would appreciate the support, I can also offer to
> >> help with maintenance, especially of things I would have to take a
> >> chance at breaking to smoothly integrate support for Windows users.
> >> Any chance you'd want to be a phone-a-friend if John does ask for
> >> support maintaining alert.el &ct in considering taking this feature
> >> in/on?
>
> I will try to help you. However, you shall know that I don't run MS
> Windows myself, so I cannot tell too much about the details of your
> implementation.
>
> >> Also, is Eli the Emacs maintainer?  I thought John Wiegly was package
> >> maintainer or more to do with Elpa somehow.
>
> Both John and Eli are the Emacs maintainers.
>
> >> I'm kinda... "new" if
> >> that isn't showing yet.  I used Emacs seriously also a couple of
> >> decades back but have only started trying to make elisp work for me
> >> these past several months.  I subscribed to several mailing lists but
> >> I won't pretend to understand all that much of what I'm reading.
>
> I'm contributing to Emacs 15+ years, but I could say the same :-)
>
> >> Coming back to Windows support relying on Burnt-Toast vs building
> >> something to use the Windows Community Toolkit (for PowerShell)
> >> directly vs writing a custom C# assembly or otherwise messing with the
> >> Emacs build, vs etc., and I find that this needs more thought.
> >>
> >> I've no trouble sharing my Burnt-Toast based solution with any package
> >> maintainer who feels it may add value.  Without question, I can
> >> implement more of WIndows Notification Center either as exposed by
> >> Burnt-Toast or with some custom PowerShell or C#.  And, if we're
> >> talking about C# then we can also think about bypassing the toolkit's
> >> API and working directly with Windows.  I think I can see where it
> >> /might/ make sense to more fully implement the API from the Windows
> >> Community Toolkit to/for Emacs, but..  maybe as a DBUS stint?
>
> 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.

>
> However, I would expect a general notification mechanism on MS Windows
> would be of use in Emacs. But Eli is definitely much better to say
> what's good on that platform.


But instead this, exactly.

>
> >> In looking at erc-desktop-notifications.el I bumped into the core DBUS
> >> functionality that Emacs ships with.  This, it seems, is too hairy for
> >> me.  Worse, the DBUS project page claims "a port is in progress" says
> >> little else to wit since 2018.  Considering that Emacs relies already
> >> on C code for optionally compiled in DBUS support it seems obvious
> >> that what's /really/ wanted here is a drop in DBUS implementation
> >> targeting native win32.
>
> If that will be widely supported on MS-Windows: yes. But still in this
> case, I believe that using a platform's native API, like the Windows
> Notification Center, might be better suited. (Saying this as the guy who
> wrote the D-Bus integration initially)


Well.  So, obviously, this does sway me, if I wasn't.  Let's don't
implement DBUS for windows.  I hear it wouldn't be fun or well used.

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. This, I suspect I wasn't explaining
well, is what I was thinking of a a "stint" (Emacs Lisp-based)  -
something that advises dbus.el, allowing it to load but supporting
only a very limited call set and, of course, invoking (directly or
indirectly) Windows Community Frame/PowerShell instead of calling into
busbind.c.  Or maybe... but nevermind that for now.  For ERC users
this could make existing tooling (al la erc-desktop-notifications.el)
work changed, leaving aside installation of the module etc. to a
little further down-message. I'm not sure how important that is vs
adding support.  I suspect a patch to erc-desktop-notifications.el
that helps Windows users would be welcome.  ++bandali   [who just
confirmed openness to this on IRC but stays tagged anyway ;]

Let's call this "Option 2. Advise dbus.el"

>
> >> What are your thoughts on focusing on a DBUS stint that is maybe
> >> native windows code and has the goal of making as much existing Emacs
> >> config as possible Just Work(sm) under Windows?  Frankly, bringing
> >> Windows to DBUSfeels better from the "Free Software" standpoint than
> >> bringing Emacs to Windows, in that it tends to standardize Emacs as a
> >> platform rather than potentially cave to vendor-specific features that
> >> could create an appetite for Emacs under non-free software.  (Screw
> >> that.)  I'd be open to contribute in this area too/instead if my
> >> limited and rusty C (and C#) skills or novice Emacs Lisp knowledge or
> >> access to proprietary personal and (maybe) enterprise operating
> >> environments could be useful but, again and still, I'd be relying on
> >> the community to help me find my way.
>
> In general, I agree with you. But I still haven't seen much D-Bus
> support on MS Windows. Widespread.
>
> (To be honest, I don't see anything on MS Windows 'cos I don't use
> it. This is just what I understand from different mailing lists. I
> could be completely wrong.)
>
> >> I can reach out to John in any case since insight into plans for
> >> alert.el (and erc-alert.el) are potentially useful in all sorts of
> >> cases.
>
> Yes. And again, if we could bring at least alert.el to GNU ELPA, this
> would also be a win.


So this is where we are, I think.

Two clear options (which aren't really exclusive), some potential for
radically different approaches (like targeting compiling Emacs with
support for the Windows Community Toolkit, when available), and a
couple of interwoven dirwctional points to consider:

1.  Should we try to create some tooling to help install Burnt-Toast
and instruct configuring it and Microsoft People and Task Bar?

This is a bit of a pain. I predict issues/frustration e.g. due to not
getting a GUID assigned to Burnt-Toast, permissions, and other things
I currently take no care to detect.

2.  And apropos, this solution isn't very robust yet, I think.

I'd be grateful for pointers expressing that more specifically and
perhaps suggesting some directions to poke in.  Capturing command
failure and sharing the message would be a favorite, I'm sure. Most
appropriate way of doing this, however, is cloudy. Just `message' and
forget?  Is is there a good recipe for balance between sloc and error
trapping (or test, ahem *blush*) code?

3. Finally, and still pretty interrelated, I think: how do we make and
evaluate our case for a change in core?  To open up the Windows
Notification Center for alerts overall, firstly, but then also to
understand what level of utility should drive, e.g. looking into
compiling against the Windows Community Toolkit and (let's say)
advising dbus.el where needed?  My thinking is that by driving the
feature back to core (with minimal impact thereto) we serve the most
people, and probably the most quickly.  If that both a correct
assessment and feasible to devise, that's the solution I guess we
should work *mostly* on.  There could be advantages for users in
looking all the way down the rabbit hole to a custom integration
between Emacs and Windows for supporting Notification Center.

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.    As background here, Burnt-Toast creates a GUID universal
for "toasts" it creates.  This GUID is a requirement for the
underlying Windows Community Framework methods and, IIUC, overall
Windows facilities exposed for Notification Center (and Microsoft
People?) interaction.  In fact, those toast really belong to Emacs and
it might make sense to look into Emacs' own procedures for having a
GUID and thus into the Emacs GUID instead of our own. I suspect a
custom native wrapper is the only route to seeing "Emacs" instead of
e.g., the attached image in the Notification Center preferences panel.

I would like to see Emacs in this panel.  I would not like to cause
Emacs to require a working C# compiler (if it doesn't already, and I
think maybe it doesn't) to create a Windows native build.  Perhaps a
glue-lib could be maintained outside of core and an optional
dependency added thereto?  Emacs can quite likely get a binary this
way, and would have sources for the win32 source depts tarball, but
would GNU maintainers end up needing to compile themselves vs using a
provided binary version?  Is/would that be a problem?

I'm pretty sure we should still build up patches starting with
alert.el and erc-nick-notify (which I found on EmacsWiki) and
erc-desktop-notifications.el is the right next move, while we discuss.
It's useful to start refactoring erc-burnt-toast into tidbits for
inclusion and understanding how different variables and helpers are
between packages.  I will plan to track stuff that somewhat closely.

>
> >> Regards warmly returned, Michael!
>
> Best regards, Michael.

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

[Michael Albinus]

Corwin Brust <corwin@bru.st> 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.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Wed, 04 Mar 2020 11:13:26 +0100
> Cc: mab@gnu.org, Emacs developers <emacs-devel@gnu.org>
> 
> 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.

Guys, you _are_ aware that Emacs has w32-notification-notify since
v25.1?  It only supports a small subset of what is possible with
D-Bus, but maybe that's enough for your needs in this thread?

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.
>
> Guys, you _are_ aware that Emacs has w32-notification-notify since
> v25.1?

Not me. I don't know what happens with Emacs on MS Windows, sorry.

And alert.el doesn't know this either.

> It only supports a small subset of what is possible with
> D-Bus, but maybe that's enough for your needs in this thread?

Corwin, you might investigate how this fits into your needs.

Best regards, Michael.

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

[Corwin Brust]

On Wed, Mar 4, 2020 at 9:56 AM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> 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.
> >
> > Guys, you _are_ aware that Emacs has w32-notification-notify since
> > v25.1?
>
> Not me. I don't know what happens with Emacs on MS Windows, sorry.
>
> And alert.el doesn't know this either.
>
> > It only supports a small subset of what is possible with
> > D-Bus, but maybe that's enough for your needs in this thread?
>
> Corwin, you might investigate how this fits into your needs.

There is one feature I cannot see how to accomplish and I'm afraid I
somewhat centered erc-burnt-toast around it.

Burnt-Toast calls this feature Shoulder Tap Notifications, but I'll
tall them "STN", here.  I find this quite useful.  STN will fall back
creating to creating normal toast/addition to stack/whatever is
configured in WIndows.  When an extra argument "person" matches the
Email address of a contact, and given that contact has been previously
pinned to the task-bar, a second additional argument "image" can be
displayed hovering over the deskop.

I use the app "Buttery Toast" to make my start menu and task-bar
"extra hidden" (they did not show unless I press the "flag" key). In
any case, I often have (several) apps full-screen.  So erc-burnt-toast
makes a someone popup and dance over my full-screen Netflix when I get
mentioned on IRC, and my friends all think I am cool, and that Emacs
is cool, and so on.

WWYT of adding "SholderTaps"?  II haven't started looking at w32's
source so not sure what technical options may exist.

>
> Best regards, Michael.

Thanks Eli.

-- 
Corwin
corwin.brust (skype)
corwin@bru.st

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

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Wed, 4 Mar 2020 16:09:52 -0600
> Cc: Eli Zaretskii <eliz@gnu.org>, mab@gnu.org, Emacs developers <emacs-devel@gnu.org>
> 
> There is one feature I cannot see how to accomplish and I'm afraid I
> somewhat centered erc-burnt-toast around it.
> 
> Burnt-Toast calls this feature Shoulder Tap Notifications, but I'll
> tall them "STN", here.  I find this quite useful.  STN will fall back
> creating to creating normal toast/addition to stack/whatever is
> configured in WIndows.  When an extra argument "person" matches the
> Email address of a contact, and given that contact has been previously
> pinned to the task-bar, a second additional argument "image" can be
> displayed hovering over the deskop.
> 
> I use the app "Buttery Toast" to make my start menu and task-bar
> "extra hidden" (they did not show unless I press the "flag" key). In
> any case, I often have (several) apps full-screen.  So erc-burnt-toast
> makes a someone popup and dance over my full-screen Netflix when I get
> mentioned on IRC, and my friends all think I am cool, and that Emacs
> is cool, and so on.

Sorry, I don't think I understand what that means in practice.  Can
you describe in more detail what this "Shoulder Taps" feature does,
and perhaps show a few screenshots?  I know very little about the new
look-and-feel of Windows 10, and even less about all the new buzzwords
they added to describe those features.

Also, it is not yet clear to me what kind of information would you
like to show in these ERC notifications.  Can you post a more detailed
description, and perhaps also tell which features of D-Bus
notifications you think you may be lacking in w32-notification-notify?
(I've read the README on the erc-burnt-toast site, but I still have
the above questions largely unanswered, probably because I don't know
enough about the Windows 10 notifications.)

> WWYT of adding "SholderTaps"?  II haven't started looking at w32's
> source so not sure what technical options may exist.

AFAIU, this cannot be done in Emacs, because the underlying APIs are
for C# programs.  So if you want this, you will have to invoke
external programs (which will have to be written in C# or compatible
languages).  That said, w32-notification-notify supports displaying
images via the :icon parameter, so I'd suggest first to investigate
whether this could do at least some subset of what "shoulder taps" do.

There's one other aspect of this discussion that bothers me: it sounds
like erc-burnt-toast is for Windows only? and there's no direct
equivalent of that for GNU/Linux?  If that's so, I suggest first to
figure out how these notifications will look on GNU/Linux (or in
general any platform that fully supports D-Bus), and only then discuss
how to do something similar natively on Windows.  The erc-burnt-toast
package is out there, so people who want it can use it; but adding a
core feature to ERC which comes with Emacs must first implement this
on GNU systems, and we cannot, as a matter of policy, have significant
features that work only on non-free platforms, without any equivalents
on free ones.