May I scream “feature creep!” here?
I don’t think such fine grained configuration is needed.
+1
I would rather like support for custom notification views (via replicant, maybe, with some standard support provides by a public NotificationView container for instance) and let app developers who really want to have custom notifications to do it by themselves, all while keeping user in control of what’s should stay in his control and not in app coder hands, position, delay, app notifications allowed or not and that pretty much all.
Indeed, an archived BView to add to the notification would be great and a nice way to use the Be API here. It would make it possible to use the notification view for download progress, tracker copy window, etc (they all need pause/resume buttons), or even a media player notification with pause/next/prev buttons, etc. All these nice things Android notifications can do.
Then the shelf to store all these notifications will become more useful and more important, too.
The delay should be in control of the app, still. For example, for a download progress, you want to show it only for a very short time, or maybe not at all, when the download starts. But then, when it completes, you want to show it again and with a longer delay. So there needs to be some control from the app, unless we can decide on some universal rules that makes sense. But going through this needs a bit of experiment with how notifications end up being used by applications.
1 Like
Talk about feature creep! 
Currently applications do have control over timeout, if one is defined when sending the notification it will override the system default.
Using an archived BView is an interesting idea. I think we’re up to phase 4 or 5 at this point, I’ve got about a year’s worth of work now 
Also please take a look at Snarl (http://getsnarl.info) - we’d love to help with BeOS notification development, especially in the network space (Snarl is compatible with Growl, can accept syslog, and has its own proprietary format)
1 Like
Phase 2 starts now. Planned features:
-Deskbar icon with menu options
-System wide notification mute (Deskbar setting only for now)
-Notification cache and history viewer
4 Likes
If anyone wants to try the bleeding edge notification server (note you will need an hrev > 51445), this is my branch:
You will need to blacklist the system notification_server. Create a file /boot/system/settings/packages with this content:
Package haiku {
EntryBlacklist {
servers/notification_server
}
}
Reboot and start the new notification_server manually.
Nice seeing your continued work!
The date headers look a bit non-standard… Maybe just make them bold and a horizontal line above it? Maybe lightly tint the date row?
Can you point me to a more standard header example?
Yes I’m going to play with the list look a bit. Still thinking of ideas, I just got the basic info there for now. One thing I have to consider is people like YOU who change the list colors , so I have to be sure to pick colors that are pretty much guaranteed to have correct contrast. Which makes my choices limited to the selected list item text/background color or the unselected ones.
I probably need to make the list items multiple lines. We have Group, Title and Content text to consider. First two are optional. A second line would also allow space below the time for an icon or status text to indicate when a message was “muted” or if it timed out without the user closing it. That way it could easily be seen which notifications were missed.
No. 
I don’t think there’s an example for headers in lists yet. I meant the rounded rect around the header looks more like something you find on the web.
Here’s a quick mockup of what I’d consider more in line with Haiku’s style:
For the time, I’d say down to the minute is precise enough.
(Hey, and mind the sentence-casing… )
I don’t think it should become too colourful. Just using the standard named colours and tint a bit up or down depending on that colour (light/dark).
Not sure going multiline is best; it doubles the length of the list…
Maybe going for a column list view is nicer. I also like the alternate light/dark rows of the e.g. Repositories prefs.
With columns people could make the columns they’re not that interested in narrower (maybe truncating the contents) or even hide them. After all, there’s still the preview at the bottom. That preview might be put in a split or expando view, so people that are just fine with only the list can hide that.
One column could hold the notification caller’s icon, so people could hide the respective column. That icon could be superimposed with a “mute” symbol when the notification came in when muted.
Your popup menu at the top can then hold “All”, “Muted” and maybe other categories.
You could add a filter text control like in HaikuDepot, to have a full text search through all entries and only show the hits.
I’d also rather have the timeline reversed: most recent on top.
Just brain-storming…
3 Likes
Looks good, Perelandra0x309! Thanks for making these changes, and writing this post.
I like all these ideas. Using a column list would add a lot of flexibility and enhance the user experience.
How about adding icons to notification history? This way it would be easier to distinguish between apps.
1 Like
Maybe grouping according notification sources (eg. Apps)
Lots of great suggestions here, thanks. I’ve completed a lot with this, maybe I’ll put up a screenshot tonight.
-Date headers now have solid background, lightened some from the selected item background color (need to add code to detect if I need to darken instead)
-Time in the form of 12:34 PM
- Use use the colors defined in Appearance, so it’s as colorful as you decide
-Stayed single lined, and I like the item list better, it is cleaner looking. I could do something like add a menu bar where you could select what data elements to show:
Show
*Time
*Icon
*Application name
*Title
*Content
-The top menu has “All” and “Muted” now. I may add a “Missed” for notifications that reach the timeout (were no clicked to dismiss them) which likely means the user missed seeing them.
-Search is a planned feature.
-Reversal of order- OK, maybe another menu to choose sort order:
Sort
*Ascending
*Descending
-Grouping by app: perhaps, I will have to play around and see how that would work. Perhaps the search function could serve as a way to filter a certain app if you search by app name.
Edit:
Oh also wanted to add, clicking on an item shows the preview on the bottom. Clicking a date header or clicking the notification’s close X hides the preview (Neato!).
Rather than menus everywhere, I would add my vote to using a standard BColumnListView which provides sorting (with primary and secondary columns), configurable columns, etc. Please don’t reimplement this with a BListView.
If you don’t like the looks, maybe change the BColumnListView code to make it look better.
As for “missed” notifications, I’m not sure about that: usually when I get a notification from Vision, either I read it and there is not much to do (the full message is included anyway), or I use Alt+F1 to get to my IRC workspace and reply there. As a result I very rarely click notifications.
2 Likes
No, there won’t be menus everywhere. If more options are added they will all be put up into a menu bar. But I think this is all I am going to do for now, just choosing either All notification or Muted notifications, and the search control.
For using column list we would need columns for Date, icon, Application name, Group text, Title and Content. A lot of times, Application name and Group are identical. Sometimes there is not group, or no title. So I think it will look very poor with lots of empty spaces, some rows having groups and titles and some having empty spaces with none. With an list view I have added logic to present all the information in a more condensed and consistent looking manner:
Perhaps the missed notifications are best left for when we get a true notification shelf to place them onto.
1 Like
I, too, almost never actively close a notification. Only if the damned thing obscures something - most of the time a download notification from Web+ keeping me from a tab behind it…
Therefore I second your notion to leave “missed” ones for the shelf.
This “Notification history” will eventually be a tab in the Notification prefs, right?
What do you think of putting another slider in the “General” tab there with the label “Retain history for:” with 0 to 14 days? “0” means no history, i.e. clears the history.
I first thought about an added button “Clear history” in the history tab, but figured that there’s really no need to completely purge the history and most of the time, you just want to have old notifications removed. Setting a retaining time in the “General” tab seems more practical.
The “Retain history” setting should be respected when switching to the History tab, i.e. showing only the set amount of days. But actually removing older entries should only be done when quitting the Notification prefs. That way, I can go back and change the setting again, if I’d have removed too many entries…
(Did I express myself clearly here…? )
The history will be saved in a separate file, I expect? That way people can easily purge their history, if they need to.
1 Like
The history window is totally separate from the preflet. It doesn’t really fit in with the concept of changing settings.
Actually adding history settings to the preflet was my very next task. I was going to add a checkbox to "Keep history for _____ " (that last part is a text view) and a menu to choose “days” or “weeks”. Retain is a good alternate word.
If I set it to only keep/retain 7 days, I don’t want to have to go to the preflet every time to clear the old data, it should be automatic. That would be my expectation as a user. So I am going to put a recurring daily message runner in the server to kick off a task to clear old cached history older than the setting in the preflet. There is one file for each day saved in ~/config/cache/Notifications and the History viewer will just read everything in that directory. The cache cleaning task simply deletes the files older than the preflet setting. That makes it easy if someone wants to turn off the feature in the preflet and clean the files up manually or with a script.
And did you notice the alternating shading on rows Just for you! Actually it was a great suggestion.
Sounds all good. I assume the history (as well as eventually the shelf) will be accessable from a replicant icon in the Deskbar? I wouldn’t like to have the History and Shelf under Applications and the prefs under Preferences. That’d feel a bit too fractured…
I’m not sure if we need such micro-precize setting. A slider is very user-friendly, if it supplies sensible values. Maybe:
never
1,2,3,4,5,6 days
1,2,3 weeks
1,2,3 months
forever
“Never” would disable the history, “forever” never deletes anything leaving the user to manually clear things.