Define better how Notifications behave

[BjarniRunar]

Currently there is a mismatch between MacOS notifications (gui-o-mac-tic) and the GTK notifications (I am unsure what the state is on Windows).

On MacOS, the notifications are stacked and there can be more than one visible at a time.

On GTK, we are only capable of displaying one at a time, and if it is already visible we just update it with new information.

The result of this, is that on MacOS, the current Mailpile notifications can be very spammy. The GTK pattern is also a bit more of a "lowest common denominator", in that we generally can't assume that we can display more than one notification at a time.

I think we have two choices:

1. Make the protocol explicitly support multiple notifications in flight at once, and either provide protocol-level tools or guidance to app writers about how to suppress "spam".
2. Make the protocol explicit about only supporting one notification at a time and mandate that GUI implementations replace or suppress on platforms that allow multiple notifications at a time.

I am vaguely inclined to go with option 2, but I'd like to open up for discussions with @peturingi and @AlexanderHaase.

[AlexanderHaase]

Option 2 seems the most direct. Windows shows the most recent notification per application, and hides the rest in the notification center(or just drops them prior to windows 10):

There are ways of working around that, for instance, custom notification windows(like google calendar). However, not sure we want to engage in that unless it's improving our UI story.

[ghost]

Choice number two is ok with me as I do not have a problem with suppressing notifications.

My argument is that macOS already allows:

• notifications to be suppressed per app via macOS's System Preferences,
• notifications to be temporarily suppressed for all apps by activating macOS's "DO NOT DISTURB" (I always do that before sharing my screen.), and
• notifications to be scheduled to be always suppressed between say 21:00 and 07:00.

[ghost]

Do we agree that 2. is to be implemented?

[BjarniRunar]

That seems to be the consensus. Lowest common denominator wins.

[ghost]

On MacOS, the notifications are stacked and there can be more than one visible at a time.

There was a bug in GUI-o-Mac-tic. The quoted behaviour is actually not the default but one I explicitly enabled early in the development cycle. I forgot to disable it again. By default, macOS shows a single notification at a time, that notification will disappear after a few seconds (defined by macOS). If an application requests the delivery of a notification while a different notification is currently being displayed, then the new notification will not pop-up, it is sent directly to the "notification centre".

This is to say that I believe that the notification mechanism in macOS and Windows 10 have almost the same behaviour.

[BjarniRunar]

That's great. Is it possible (without jumping through hoops) for the new notification to bump the old one and display instead?

[ghost]

Is it possible (without jumping through hoops) for the new notification to bump the old one and display instead?

There is a way but it involves deleting the current notification.
Doing so is bad because:
This removes any traces of it from the "notification center". Also, the old notification would animate out and a new one would animate in (its not a mere text-update, the user sees an old notification go out and a new one coming in). A user who did not manage to fully read the old notification would expect to find a copy of it in the "notification center". He would not be able to find it in there because deleting a notification involves both removing it from the screen as well as from the "notification center".

[BjarniRunar]

That sounds a bit like a feature to me - not spamming the notification center. The animation strikes me as more of a concern, that's a lot of visual noise for potentially low-value updates. Let's leave this as it is for now.