Implement a Haiku notification Center

[richienyhus]

Haiku needs a Notification Center app that shows the most recently received notifications and provides a shortcut to the notification preflet.

Notifications that have been ignored, dismissed or silenced (when temporarily turned off) are shown here to allow the user go back and read them to check if they haven't missed anything important.

There are equivalent applications on most other operating systems, including ​OSX and ​Windows.

[pulkomandy]

the notification preflet already does (did?) include some UI for that, but AFAIK the backend was never added. The Notification system currently does not store or archive the notifications in any way. This is not too hard to implement, however.

[perelandra]

I would like to try this, I have often wanted to go back and see a record of notifications but was disappointed that feature is not working yet. One thing I might suggest though is not to store the norification history in the settings file. Would saving them in the cache folder be better?

[pulkomandy]

Yes, it makes sense to use the cache directory for this.

How it should work/The way I see it:

• The notification server (or an add-on in there) stores the notifications to the archive. The simplest way is to Flatten() the notifications using BFlattenable/BArchivable support, unless a text format is desired
• The notification preferences (or "notification center", if we make it a separate app) finds all notifications in the directory, unflattens them, and shows them (with buttons to dismiss/delete, etc).

[perelandra]

I have notifications being archived by the server now. Under /boot/home/config/cache/Notifications I am saving one file for each "group" notifications are sent to. This file is a flattened BMessage, which stores BMessages containing data for each notification received by the server. Each of the notification data messages stores: -A copy of the original notification BMessage received by the server. This preserves all notification data including onclick values. -A timestamp when the message was received by the server. -A bool indicating if the notification was shown when it was received. Looking at the code indicates there were plans to implement filtering to disallow specified notifications from being shown. If we do this, then now the notification can still be archived to view later even if it is not shown when sent.

Looking at the current Notifications preflet the way it is now would only show limited information about archived notifications, no icon or onclick info is preserved. I am thinking maybe we can change it so that instead of a ColumnListView just showing text data we should actually preview the notification view as it was displayed. Saving the entire original notification message as I have done should make that possible.

[pulkomandy]

Yes, no problem with improving the layout of the preferences. It should be possible to instanciate a notification view in the preflet and add all the notifications to a BGroupLayout + BScrollView.

However, BColumnListView could also be considered, with custom columns to show all the info (icon, etc). It is interesting because it also provides keyboard navigation and sorting.

Without giving it further thinking, I am undecided between the two approaches. Reusing the existing notification view sounds simpler, so maybe go with that and experiment a little?

[perelandra]

PulkoMandy,

Looking at the NotificationView code the constructor requires a pointer to the NotificationWindow it is being added to. So it won't be as simple as just creating a NotificationView and adding it to some view in the preflet. But perhaps this could be accomplished by having a ColumnListView with all the details as you said, and then provide a button like "Show Preview" which would create a NotificationWindow and add the notification to it. Maybe "stick" the NotificationWindow to the bottom or side of the preflet window?

I forked haiku's git last night and setup my build environment but we are dealing with an ice storm and power outages now. I should have something up in a few days to show.

[perelandra]

I currently have notifications being archived (in /boot/home/config/cache/Notifications) and added a "History" tab to the Notifications preflet that shows a column list view of cached notifications. I sort of got a preview of an archived notification working however it was a major hack because the NotificationView is heavily tied to its AppGroupView parent and the NotificationWindow class which is actually passed as one of the constructor parameters.

So I'm going to take a break from that for a while and start working on what I think of as the notification "shelf". This will be another NotificationWindow where notifications that timeout are placed. Like other OSs it will live off screen until the user asks for it. Maybe a deskbar shelf icon? So if you miss any notificiations you can view them here. Thoughts?

[perelandra]

I finished a very basic notification center shelf. I basically created another NotificationWindow in the server to be the shelf where all timed out notifications will live until they are closed by the user. If a new notification times out it is removed from its current notification window and sent to the shelf window with the timeout disabled. I reuse the axact same view so it looks identical. Maybe it should look different in the shelf so it is more compact for times when lots of notifications have timed out? Well that can be a poitn of discussion.

Attached are a screenshot of the shlef with notifications that will not time out and need to be manually closed, and just a diff output if you are interested in the changes needed to accomplish this. It was surprisingly simple. However missing are some needed features like shelf auto-hide and having some icon in the deskbar or somwhere else to show shleved notifications.

[perelandra]

Notification Center demo

[perelandra]

Diff of changes

[perelandra]

Or this commit: ​https://github.com/Perelandra0x309/haiku/commit/03ded6c77e79a14b0ad5bc7e68210f9fb2323ee4

[humdinger]

I tried your changes, and I confirm: notifications now have to be clicked to disappear. :)
Anything else I can test?

Maybe it should look different in the shelf so it is more compact for times when lots of notifications have timed out?

That and/or try how it looks if the the text isn't black but dark-grey and the background a little darker (might look horrible, just a thought...)

[pulkomandy]

I would just fold the apps/categories by default (with the number of notifications under in parentheses, if that is not already there). The list of apps should be small enough to fit the screen, then you can open them one at a time and handle the notifications inside. If it grows past the screen height, maybe we will need to consider adding a scrollbar?

[diver]

Maybe only fold them if the number of notifications is relatively small, say <5 ?

[perelandra]

Humdinger, here is the shelf with a darker background. I like it, and if it is displaying and a new notification appears you will know the difference by the color.

[perelandra]

Replying to pulkomandy:

I would just fold the apps/categories by default

Well my initial thought would be to have the notification center hidden, and when notifications are placed there put the notification server's icon in the deskbar shelf so the user would know there were notifications in the center to view. Clicking the deskbar icon would show (and hide) the shelf. That's similar to current OSs.

However I think you may be having a different idea, if I get your meaning. Are you saying always show the notification center but when it has notifications add them collapsed into the group header (and yes there is a number in paraenthesis to indicate how many there are)? I see two disadvantages:

1- You have to click each group header to display the notifications to read them. If you have 5 groups that is 5 clicks just to read them all. With one deskbar icon you can show/hide all with one click.

2- Let's say you have 5 and they are collapsed, you must close them (after supposedly reading them) to gain back that screen real estate. If you don't have a show/hide feature that forces the user to close them to get that space back. If you do have a show/hide feature (the user doesn't want to read them right now), you are again adding more clicks for the user to be able to read them.

Personally I would rather have the center hidden and a show/hide icon in the deskbar and have all notifications initially viewable. However maybe someone else would want the notification center initially shown with new notifications collapsed into the header? And also have the hide/show option? That could probably be a setting preference.

[pulkomandy]

What I'm worried about is this: let's say I leave my computer on during the night with IRC running. Someone sends me a lot of private messages (which each result in a new notification). At the end I will have a very large notification history, which will not fit my screen. And I can't see if there are other apps with notifications.

This is why I think the current view may not be suitable for a rather large history of notifications. It was not designed to scale that way. This is why the preflet has plans a much more compact list view instead. This way you can archive a day or a month worth of notifications and it remains usable.

For the darker notifications, I think this would not blend well with the rest of the OS. I would do something more subtle, like changing the left "stripe" (the one below the icon) only (it can already change color for "error" and "success" notifications). An alternative is drawing the text and icon with some transparency, which would "fade out" the notification, without changing its colors. I would also leave the title part with its normal colors, bacause archived and new notifications should still group together if they are in the same category.

[perelandra]

Here I only make two changes between the new notifications and the ones in the notification center: Notification text is LIGHTEN_1 and group header background is DARKEN_2.

[perelandra]

Replying to pulkomandy:

What I'm worried about is this: let's say I leave my computer on during the night with IRC running. Someone sends me a lot of private messages (which each result in a new notification). At the end I will have a very large notification history, which will not fit my screen. And I can't see if there are other apps with notifications.

Maybe we can extend the NotificaionWindow class to a NotificationCenterWindow class that makes a scrollbar if there are too many notifications to fit on the screen.

This is why I think the current view may not be suitable for a rather large history of notifications. It was not designed to scale that way. This is why the preflet has plans a much more compact list view instead. This way you can archive a day or a month worth of notifications and it remains usable.

I don't want to have to open the Noticiations preflet to see the notifications I missed. Too much work. They should be available with one click.

For the darker notifications, I think this would not blend well with the rest of the OS. I would do something more subtle, like changing the left "stripe" (the one below the icon) only (it can already change color for "error" and "success" notifications). An alternative is drawing the text and icon with some transparency, which would "fade out" the notification, without changing its colors. I would also leave the title part with its normal colors, bacause archived and new notifications should still group together if they are in the same category.

I think maybe you are not understanding there are two NotificationWindow instances. One for the new notifications (that will time out), and one where notifications that time out are "shelved". That way if you have old notifications in the shelf any new notifications appear without covering your sceen with all the old shelved ones. If you get a whole ton of shelved notifications (overnight let's say) you can close them all by closing the entire group header. Or a shelf with a scrollbar would help.

[perelandra]

To make it clear in n_center3.png, there are 3 "shelved" notifications in the notification center window. This window is behind one new notification. New notifications are in their own window. So if I hide the notification center, only the new notifications will show up without showing all the old notifications.

[pulkomandy]

I don't want to have to open the Noticiations preflet to see the notifications I missed. Too much work. They should be available with one click.

This is not incompatible. We can have a deskbar replicant that opens the preflet with the right tab active, or a separate window. Anyway, my main point is I would rethink the look of the notifications in that case, and try to go for something more compact than the normal view.

I think maybe you are not understanding there are two NotificationWindow instances. One for the new notifications (that will time out), and one where notifications that time out are "shelved". That way if you have old notifications in the shelf any new notifications appear without covering your sceen with all the old shelved ones. If you get a whole ton of shelved notifications (overnight let's say) you can close them all by closing the entire group header. Or a shelf with a scrollbar would help.

Ok, why not. I think the "shelved" ones could be in a regular window (with window border, that you can move around), and yes, most likely with a scrollbar. Wether to integrate that with the preferences or as a separate window, doesn't matter much. But I think it should be a normal window that I can move around, minimize, etc?

[perelandra]

Replying to pulkomandy:

Anyway, my main point is I would rethink the look of the notifications in that case, and try to go for something more compact than the normal view.

Yes it should be possible to make each notification view more compact, I just haven't tinkered with that yet.

Ok, why not. I think the "shelved" ones could be in a regular window (with window border, that you can move around), and yes, most likely with a scrollbar. Wether to integrate that with the preferences or as a separate window, doesn't matter much. But I think it should be a normal window that I can move around, minimize, etc?

Hmm, a normal window that you can move around/resize. I hadn't considered that, I was just using the same non-movable always-on-top window the new notifications use. A full window would seem less integrated into the OS, but more like an application. Let me see though, maybe there could be a menu where you can select what to view: -View missed notifications -View all notification from: --Today --Yesterday --The last week --The last month --The last year

And maybe a menu to select a filter by group, or a text search box. This window would eliminate the need to have most of what I put in the preflet, perhaps all that would be in there is a way to clear the archive cache wholesale or by individual group.

[axeld]

Here's my take on this: the pop up notifications (as what happens now) should be optional -- it should be possible to only ever see the tray icon. When you click that notification tray icon, the window comes up (that could look pretty much like it does in perelandra's screenshots), but has a scrollbar. It will show all current and earlier notifications, probably with some kind of a separator in between.

The list should only contain a certain number of entries, at the bottom then comes a button "Click here for earlier notifications" which takes you to the notification preferences application's history tab.

All the filter, ordering whatever abilities I would put only in the preferences application, and have the tray "app" as simple as possible.

[humdinger]

With hrev50876 I added some notification icons that might be used for lists and in the Deskbar etc.

[perelandra]

I agree with axeld, I like simpler better. It seems more like a core OS function than a separate app. Open the center, view your missed notifications, dismiss them and done. If you want more features then those can be in the preflet under the history tab.

And there were plans it looks like to enable turning notifications off per app, and there is already a checkbox to turn off notifications altogether. If we want to add an option to disable pop-ups (have notifications go directly to the center) that isn't too hard.

[perelandra]

Replying to humdinger:

With hrev50876 I added some notification icons that might be used for lists and in the Deskbar etc.

I appreciate these, but not really sure how these align with notifications. The types of notifications are information, important, error and progress.

[humdinger]

I'd pick Notice for information, Achtung for important, Danger for error. Not sure what "progress" would be.

Maybe in the future the failue states will become more fine-grained, then Caution and Warning may come in handy. (BTW, I thought since the U2 album "Achtung! Baby" would be recognizable enough. We can change the file name, of course. :))

[perelandra]

U2 and Scorpions, two of the all time best! Lots of great times and memories and I was still listening to them in college during the BeOS years. (See how I tied that in there, I'm not completely of topic!) :-)

[perelandra]

Here's what I have so far. The deskbar replicant is displayed (no back end messaging yet). And I have the notification center with a scroll bar displayed (automatic scrollbar sizing yet to be done). But I can set the scrollbar size manually and had to move some drawing out of the BGroupView class into a new BView class since it was doing some custom drawing causing the group header to draw over the Notification Center label view.

[perelandra]

Latest commit: ​https://github.com/Perelandra0x309/haiku/commit/1e379c5791ed957286c20c867313d911a970dba3

Deskbar replicant now shows/hides notification center. Scrollbar on center not programmed yet.

[perelandra]

I now have a deskbar replicant icon that displays a red dot on the icon when new notifications are added to the notification center. It resets back to the standard icon when the center is displayed (and presumably you have read and possibly dimissed the new notifications).

[richienyhus]

Very nice!

You should post an update to the Haiku development mailing list, since that is a wee bit more high profile and won't get lost in all the bug tracker's noise.

[perelandra]

OK I think this is going to be my last commit for a while, I am going to let this simmer and give people a chance to try it. ​https://github.com/Perelandra0x309/haiku/tree/n_center

Things remaining todo: Add a string view to the notification center when there are no notifications in it (something like "There are no new notifications"?) Fix notification layout issues for different larger font sizes Use bitmaps for the center buttons at top ("Settings" and ">") Automatically show the center if the show/hide replicant fails to be added? Show a scrollbar when notifications fill up the height of the notification center View/search notification history (I have much of this written in another branch but not added here) Fix Notifications preflet (Revert button doesn't work, Apply button doesn't enable until you press TAB, do there need to be two checkboxes under General or can the same thing be accomplished with one) Archive the center notifications to preserve over a reboot/crash Split the NotificationWindow class into two Window classes. Currently the one class is being used for both the popup notification window and center window when they really behave in different ways and have different layout elements.

If there is an easier way to provide the notification_server for others to test please let me know. Maybe I can zip up and add as attachment? Is that allowed?

Please make comments if you try it.

[perelandra]

Screenshot showing the notification center and the deskbar replicant displaying the icon for indicating new notifications have been added. I made the center full height (like Mac) but I have also done it auto-resizing to the height of the notifications.

[pulkomandy]

Full-height will look strange with the default DeskBar position (on the side). Be gave up on full-height deskbar some time after BeOS DR8 :)

​https://qube.ru/files/images/beos_dr_8_powerpc_bebox.gif

[humdinger]

I'm using the notification center now for a bit and see how it feels. Here are my first findings:

• I agree with pulkomandy that I'd rather have it in a normal BWindow. I'm so used to get rid of a window with ALT+W that it's awkward having to aim with the mouse to some widget for that.

• Removing a notification by clicking on it isn't what I expected. Some notifications do something when clicked on, e.g. downloads from Web+ are opened. I may want to do that, but not yet dismiss the notification. I suggest only reacting on the click on the "x" widget and have that on every notification (right now it is suppressed if there's only one notification in the 'group'.

There could be a vertical separator to the left of the widget, and the whole right side with the widget reacts on a click. Makes aiming easier (mockup):

• It would be nice to be able to see when the notification arrived. Maybe with a BToolTip. Ideally, it should say "23 minutes ago", "over 2 hours ago", "Yesterday", "26.08.2016, 16:35" depending on locale etc.

But I guess we better leave this sort of thing to future enhancement tickets...

[humdinger]

mockup of close widget

[humdinger]

Showing the Notification Center is using massively CPU in two threads in the app_server.

[perelandra]

Replying to humdinger:

I'm using the notification center now for a bit and see how it feels. Here are my first findings:

Awesome, thanks so much for testing!

• I agree with pulkomandy that I'd rather have it in a normal BWindow. I'm so used to get rid of a window with ALT+W that it's awkward having to aim with the mouse to some widget for that.

It is a window so we might be able to add key commands to it. They would be assigned to hide, not close.

• Removing a notification by clicking on it isn't what I expected. Some notifications do something when clicked on, e.g. downloads from Web+ are opened. I may want to do that, but not yet dismiss the notification.

Yes this is the default behavior from the way popup notifications were programmed. It does make sense for the ones in the center to behave a bit differently. Easy change.

I suggest only reacting on the click on the "x" widget and have that on every notification (right now it is suppressed if there's only one notification in the 'group'.

Another easy change.

There could be a vertical separator to the left of the widget, and the whole right side with the widget reacts on a click. Makes aiming easier (mockup):

Cool idea.

• It would be nice to be able to see when the notification arrived. Maybe with a BToolTip. Ideally, it should say "23 minutes ago", "over 2 hours ago", "Yesterday", "26.08.2016, 16:35" depending on locale etc.

Yes I had considered that, as well as maybe altering the notification layout. I don't think the insets need to be as large when the notifications are in the center. That would allow more of them to fit on the screen. With the popup notifications the larger insets aren't really an issues since it is unlikely to have a large number of notifications at once.

But I guess we better leave this sort of thing to future enhancement tickets...

Well this is no where near release ready yet... :-)

Showing the Notification Center is using massively CPU in two threads in the app_server.

Hmm I had not seen that. Is it the two window threads? I will check this out tonight. Are you running virtual or bare metal?

[humdinger]

Replying to perelandra:

It is a window so we might be able to add key commands to it. They would be assigned to hide, not close.

The window should be resizable and moveable, so having borders and a tab is needed, as well as saving those properties.

Showing the Notification Center is using massively CPU in two threads in the app_server.

Hmm I had not seen that. Is it the two window threads? I will check this out tonight. Are you running virtual or bare metal?

ETA: After I have cleaned the Center from all notifications, closing and reopening the now empty Center doesn't use CPU visibly.

Metal all the way, man! :)
These are the threads:

[pulkomandy]

That would allow more of them to fit on the screen. With the popup notifications the larger insets aren't really an issues since it is unlikely to have a large number of notifications at once.

This can happen rather easily also with normal notifications. Example: I connect Vision to an IRC bouncer, which means that when I start it, it replays the conversations from the night. If someone sent me private messages, each of them will result in a notification at that time.

So, I don't see any problems with a more compact look, even for the normal notifications.

[perelandra]

I checked the cpu usage last night and I also see some but only when the notification center window is shown and has notifications in it. If it is empty or hidden there is no cpu usage. I did some debugging and it doesn't look like the app server is in a messaging loop with that window, I added a printf first thing inside the NotificationWindow MessageReceived and got the expected number of calls to it, no runaway repeated messages. Unfortunately when I try to debug the app_server my system totally freezes. The fortunate thing is the CPU usage does not increase with more notifications or groups, it seems to be a steady usage as soon as one is added but stays the same after more are added.

I'll look into it further when I return to modifying this server after I get more feedback. On my Core2 it is only using about 1/2 a core and only when the center is displayed so it shouldn't cause any system to be totally hosed by testing it.

[pulkomandy]

The app_server messages are not going through MessageReceived, they use a dedicated protocol using app_server link. So you won't see them in MessageReceived.

Typical causes for this are a chain of events causing Draw() to Invalidate() the view, or maybe there is B_PULSE_NEEDED in a view flags somewhere and the pulse rate (SetPulseRate) is unreasonably short.

[perelandra]

Expanded the close area to the tinted area on the right.

[perelandra]

I have added the ability to close the Notification Center by either clicking on the top label (gives you a nice large target) or by pressing the ESC, CMD-W or CMD-Q keys.

[humdinger]

Nice! I still like a completely normal window better, not least of all because now an empty grey wall hides my ActivityMonitor replicant I have on the bottom right. :)

With these changes, I now see the linebreaks of the info text being unnecessarily narrow:

(those vertical lines are some artefact when taking a screenshot. I see this in several places, things being transparent...)

Maybe too complicated to implement for a first draft, but it'd be nice to have the closing-widget-area react on mouse-over like a BButton. Maybe a BPictureButton can be used? It doesn't have to be tinted...

[humdinger]

I may have to retract #comment:36. Other notification don't show this narrow linebreaking. They do, however, come precariously near touching the vertical separator line to the click-to-close-area to the right. A little padding might be in order.

[perelandra]

Replying to humdinger:

I may have to retract #comment:36. Other notification don't show this narrow linebreaking. They do, however, come precariously near touching the vertical separator line to the click-to-close-area to the right. A little padding might be in order.

The changes I made should not have changed the line width in the notification, all I did was add drawing the bar on the right. So I think the line breaking for the ActivityMonitor is in the text string itself (tsk, tsk), and yes I did notice that longer messages are getting covered over by the shaded area so I need to fix that.

It should be possible to make a setting to choose whether to have the window free floating or fixed. But first I need to break the NotificationWindow class into two separate ones. I am using the one class for both the popup notifications and the notification center and the behavior of each is becoming different enough to need separate classes now. There are some changes to other classes I need to make first before I can do that.

[humdinger]

Maybe you can introduce a setting for the closing-bar to the right, too. It's not really needed when it's in a notification when it's popped up and disappears after a few seconds, I'd say.

BTW, this ticket's comment thread gets awfully long. Shouldn't we better create new tickets for every bug and enhancement?

[axeld]

Since the proposed component is not part of Haiku yet, maybe just move this discussion to the mailing list instead?

[humdinger]

Agreed. Let's use ​Testers needed for updated notification_server for it.

[thaflo]

Hello! Following the mailing list I there is a 404 on the page where testers could try the notification center. On github pages from perelandra I can't find it. Any news on this ticket?

[pulkomandy]

There are 3 branches in Perelandra's repository:

• ​https://github.com/Perelandra0x309/haiku/tree/notifications
• ​https://github.com/Perelandra0x309/haiku/tree/notifications_phase1
• ​https://github.com/Perelandra0x309/haiku/tree/notifications_phase2

They are all a bit newer than the latest discussion here, and I guess they include at least that work?and I think they build on each other with the "phase2" one being the last iteration.

This will need a little work to resync it with current Haiku sources, but the Notifications code has not changed all that much, I think, so it should be doable.