No notifications on Windows

[terghalin]

There is no notifications while running matterfront 1.1.1 on Windows 8.1.

[teetrinkers]

You are talking about the HTML notifications, not the unread count in the app icon, right?

Matterfront 1.1.1 ist based on Electron 0.34 and does not support notifications on Windows. Matterfront 1.2 is based on Electron 0.35 (I think) and supports notifications on Windows with a few caveats. The Electron docs say:

On Windows 10, notifications "just work". On Windows 8.1 and Windows 8, a shortcut to your app, with a Application User Model ID, must be installed to the Start screen. Note, however, that it does not need to be pinned to the Start screen. On Windows 7 and below, notifications are not supported. You can however send "balloon notifications" using the Tray API.

We should probably put that in our Readme. And I think we haven't testet notifications on Windows at all.

[terghalin]

Both. :) Just minimized app and nothing. Private messages, town-square - tray notifications just don't show up.

I also tested it with Matterfront 1.2 - same problem. May be Electron is not responsible for this, 'cause i checked electron-mattermost - notifications are in place (electron 0.35.1)

[geekytime]

So I refactored and tested the notifications in Windows 7 as part of #67.

Although there's no support for the growl-style notifications that Chrome uses, the basic support for notifications works like this on my machine:

• If there's a message in a channel that I'm NOT IN (regardless of whether the window has focus), the tray icon shows a little red badge.
• If I am mentioned in a channel that I'm NOT IN (regardless of whether the window has focus), the tray icon bounces to get my attention

That PR also adds support for multiple teams in tabs, and shows the unread and mention counts next to each team icon. One strategy to fix the "unfocused windows don't trigger notifications" problem would be to scrape the window title, as Mattermost 1.2 puts a little * in the title if there are messages while the window is unfocused.

[ninja-]

@geekytime my idea for this is to steal webkit notifications from mattermost and use node-notifier instead

as for how this should fully work imo(any comments?):

tray icon: red when mentions, blue when no mentions, rendered sum of mentions and non-mentions (tray icon + windows taskbar icon) on osx: don't make the icon red, but bounce instead. or make the icon red if users wouldn't like the bounce?

Slack for mac I think displays a "." badge if there are new messages but not mentions. That seems pretty cool :)

notifications: pass what mattermost gives to webkit notifications to node-notifier. I am not fully sure between node-notifier and electron notifications... https://github.com/atom/electron/blob/master/docs/tutorial/desktop-environment-integration.md (I think we should mix both APIs to get best experience on all platforms.)

Also, I am not sure about how this stuff should mix with mattermost's per-channel "send desktop notifications" settings? If users would like notifications only for mentions(or even "never"), should we ignore that when rendering the badge? There's also per-channel "mark channel unread" which is close to slack's mute button.

That's some complicated logic here and I think most of it should go to mattermost and we should only display results.

I think we should write spec not to get lost in this + get perfect user experience in the future?

[geekytime]

I tried hijacking the notifications object at one point, but for some reason it felt like a dead end, and now I don't remember why. I'll have another look when I'm back at my computer.

In the long run, I think it'll be important to understand the difference between unread counts and notifications, too. People may not want pop-up notifications, and still want to see badges/jewels for unread counts, mentions, etc.

We'll also have to be careful to balance our settings with the mattermost web client settings for notifications.

On Fri, Dec 18, 2015, 10:30 AM ninja notifications@github.com wrote:

@geekytime https://github.com/geekytime my idea for this is to steal webkit notifications from mattermost and use node-notifier instead

— Reply to this email directly or view it on GitHub https://github.com/lloeki/matterfront/issues/62#issuecomment-165826691.

[ninja-]

@geekytime it's tricky to get right for every platform, but the good news is that that I am almost done with full spec for it (every platform + integration api)

[ninja-]

@geekytime here are my notes so far, should clear some things up. https://gist.github.com/ninja-/2455eae36412120f8d49 Need to decide whether we are implementing & upstreaming the integration api + implementing new features on it, or you need it to start working asap(your recent tabview PR for example, which is quite hacky)?

[LongLiveCHIEF]

@ninja, since we merged #67 last week, does it resolve the needs you had for this?

[ninja-]

@H3Chief I am not exactly sure. My intention here was to do a full spec for dock/tray/taskbar/notifications for every platform(because it's tricky to get perfect user experience like slack does, including cool settings for each platform) based on how slack does things nicely(link up). It's quite easy to implement all of it if you want to have a look.

But first with notifications work, I think integration api should be upstreamed to mattermost first(provides mentions and pending messages). There's a limitation in the hacky dom notifications count reader that it can't see data about current channel, because there's no badge rendered. I did start implementing the integration api that passes data like mention counts and other, are you interested in upstreaming this to mattermost? (see https://github.com/lloeki/matterfront/blob/master/src/browser/mattermost-observer.js#L39)

But look, since hack is a hack anyway, you can get these mentions from global.ChannelStore for now

[LongLiveCHIEF]

I'm interested in hearing more about what you mean by upstreaming. The initial implementation was aimed at getting the most we could out there to users quickly. We also want to be cautious about spending time on anything that might soon wind up being implemented natively into Mattermost, or made available for us to consume via an api.

I think the basic concept of what this issue was opened to achieve has been met, so I want to close the issue. Your concept sounds like it could be a very good logical candidate for next steps to build on what we've already implemented, and it's more specific than just "No notifications".

I would like to see you open a discussion as a new issue, and explain a bit more about the round-trip. I'm not sure where these events would be received by Mattermost, so specifically I'd hope you could address that.

I like to keep issues relevant to either a scoped achievable solution, or a defined decision that can be made, so that they stay fresh. It's too easy for old issues to fall off the radar and be forgotten.