Feature Request: Notifications

[romainrichard]

I can think of 2 types of notifications:

1. Pop-up
2. Sound

They don't have to be decoupled, but the more options the better!

[marcel-valdez]

I think instead of doing something specific for notifications, we should allow users to execute any binary and we give that binary 2 parameters.

1. author of message or custom nickname if set
2. body of the message

So this way users can do whatever they want... sound, desktop notification, create a file, send an e-mail, log the notification? whatever the user wants.

This is fairly easy.

[marcel-valdez]

Addressed this in this PR: https://github.com/Alex-Rose/fb-messenger-cli/pull/80

[sarangjo]

We could also maybe provide some presets for sound, desktop notification, etc. for various platforms? Just so that users don't have to go through the trouble of figuring out the command-line details!

[slashome]

Still open but I can see the pull request have been closed, also I really need that feature to fit my i3 / dunst configuration :/

What is it about this feature ?

[p1ho]

What about using something like node-notifier?

Then as soon as new message comes in, it can:

1. check if terminal is in focus
2. if not in focus, check if the message thread is set to mute (I'm not sure if that info is available in the api, though)
3. If it's not muted, push a notification

Can probably have this thing fire at most once/sec so it does not become too obnoxious

[Alex-Rose]

I tried a while back using node-notifier but I think it wasn't reliable on Windows so I decided not to merge the PR. Possibly the problem is that node-notifier uses an old compiled executable of snoretoast. Perhaps updating the executable would help or even better writing an actual node module to interact with the native notification API would the best solution.

[p1ho]

@Alex-Rose I see, I'll have to dig around first to make well informed comment then.

However, I am running on Windows 10, so if you still have the PR you didn't merge available (which I'm guessing is not #80 ), I can play around with it w/ all dependencies updated.

Do you remember what aspects were unreliable, and if they're reliable now, would you consider merging the old PR?

[Alex-Rose]

I never committed my attempt at notifications. As far as I recall it was simple to set up, but did not work how I expected it on Windows. Notifications would sometimes not show up, I suspect it had something to do with registering the app to show a notification. It can be hard to debug because registration issues aren't always surfaced to the developer, there are cases where ShowToast will return S_OK but will fail anyway...

Any node app (or win32 app) will have to go the long way around to use the native notification platform on Windows. That means consuming the API, registering with the platform, declare an activator and add to to the registry, implement said activator (must be COM), then you can start sending toasts.

If the updated version of node-notifier or its dependency work, it would save a lot of effort. Though I still think it would be cool to have an actual native solution for node.

[p1ho]

I see... hmm I mean if the notification not showing up is not something that can be reliably reproduced, it'd be hard to debug. I think I'll play with node-notifier first, I'll put my updates here as I go.

[p1ho]

@Alex-Rose I played around with node-notifier. I initially just put the relevant code in pull.js right before where it emits the 'message' event. It seems to work pretty well and consistent for me, so I was gonna go ahead and implement it further, then...

I found out that there were node-notifier code written in interactive.js and they were just disabled by this line in settings.js (If .settings is already generated, then you'd have to change desktopNotifications to true)

However, since node-notifier isn't included in package.json, even if that line were set to true right now, it'll throw an error unless node-notifier is also installed globally.

I also think the actual implementation may be outdated. For testing, I moved the notifier code outside the if statement, and it does execute every time I send a message, but no notifications when messages are from other people. Turns out that the message object does not contain a key called users, and thus nothing gets returned on this line which explains the weird behavior.

I found that the message from other people takes the following form:

{
  type: 'msg',
  author: '<author-id>',
  body: '<actual-message>',
  otherUserId: '<id-of-person-you-are-talking-to>',
  threadId: undefined, // For some reason, this was undefined for me
  timestamp: '<unix-time>'
}

A function that converts author-id to name should solve the issue of notification not popping up.

Aside from that, I think if this feature is to be re-enabled, a mechanism that pools all notifications in the last second should be there, because right now on Windows, it'll just flood the action center if someone wanted to spam you.