Notifications preflet changes

Development
21

I guess the main use cases are games and media players. In these two cases it may also be a good idea to also disable the screen saver, so this is more global than just sending a message to the notification server.

22

I would like to get something committed to master before any branch to beta1 is made, so I am going to roll this out in phases. Phase 1 will be to just get the preflet working properly, cleaned up and add the ability to mute notifications by app. That seems to be a reasonable goal with the time I have. Later phases will add more features.

Here is what I have got for phase 1, almost ready after some testing. Notification settings with live view when changes are made:

image.png740×597 49.7 KB

New mute feature:

I have also fixed several issues with the code that were just broken, improved the notification layout a bit and fixed issues with bold fonts not using the system size.

3 Likes
23

Very nice! It finally looks like the rest of Haiku prefs. Before it always looked kinda alien to me.

24

Good plan!
Maybe using “General” as in the Screensaver prefs instead of “Settings” would be a better tab label. Or keep “Display”? Or “Look” á là Appearance prefs?

WRT the “Applications” tab: How does it work? Do any apps showing notifications automatically appear there or do I have to use the “Add/Remove” buttons to manually add/remove an app’s notifications?

Does the “Mute notifications” checkbox mute all notifications (then its label should say so)? What’s the difference to the first tab’s “Enable notifications” checkbox then?
Or did you plan that this checkbox only toggles the status of the selected app in the list above?
IMO it’d be a nice idea to do it similarly to your Repositories prefs panel: a double-click or the “Enable/Disable” buttons toggles the status (also named “Enabled/Disabled” instead of “Allowed/Muted”). And, if really needed, those “+/-” buttons instead of “Add/Remove”.

25

[quote=“humdinger, post:24, topic:6090”]
WRT the “Applications” tab: How does it work? Do any apps showing notifications automatically appear there or do I have to use the “Add/Remove” buttons to manually add/remove an app’s notifications?[/quote]
Right now they do not add automatically, just manually in the preflet. I did think about adding automatically for a future update. I would need to add the ability for the server to save changes to the notification settings file (it only reads now), and add code for the preflet to detect and reload changes made by the server. To do in a future phase.

[quote=“humdinger, post:24, topic:6090”]
Does the “Mute notifications” checkbox mute all notifications (then its label should say so)? What’s the difference to the first tab’s “Enable notifications” checkbox then?Or did you plan that this checkbox only toggles the status of the selected app in the list above?[/quote]
The setting (or future settings) here in this tab are per application, so the mute is specific to the application selected.

Yeah a bit more explanation is warranted. I am envisioning in a future phase to have other application specific settings. For example being able to disable the notification timeout or specify a different timeout than the system default. Or perhaps choosing a different screen location than the system default. Then it is more complicated than just a simple enable/disable option. I would also change the application list to a ListItem view, and do something similar to SoftwareUpdater and have the options for each app displayed as extra text lines and add an icon.

And about the use of the term “mute”. In future (again) will be the ability to view a history of all notifications received, or some type of shelf for notifications that timeout (user does not click to dismiss) and get sent to for viewing later. Like MacOS or Gnome. So “mute” does not disable notifications, it just prevents them from being displayed as the pop-up. The notifications will go directly to history/shelf. So you can “mute” notifications and you won’t see them pop up but will see them in history. This to me is different than “disable”, which would not allow the notification at all, so would keep it from showing in a history or shelf.

But since we do not have a history or shelf yet, for now mute will be in effect the same as disable. In a future phase is planned a deskbar tray icon, where you can “mute” all notifications at once. So you will not get any popups, but any notifications will still go to history/shelf for viewing later. That would be different than “disabling” the notifications, which totally shuts the server off. I hope that makes sense.

Edit: We had used the phrase Do Not Disturb before. Would that be better than mute?

26

Here’s a workflow I whipped up:

image.png438×596 7.2 KB

27

Thanks for the details. All makes sense now. :slight_smile:

I actually like “Mute” better. The only potential confusion is that it could be confused with only muting a sound people could assign in the future. If that will be possible, the question is: will the sound be assigned in the Sounds prefs, as it is now for Vision nick notification, or is it all kept in the Notification prefs. Hmm… maybe it can even be available in both panels.

28

I still think having a log of all notifications instead of just a shelf for ‘missed’ ones would be better. One could still filter for missed ones …
Then at the end, it’d always be sent to the log, wether it timed out or was closed by the user.

29

That’s what the “history” is. An archive of the notifications so they can be searched. The shelf would just be a temporary location for missed pop-ups (or if pop-ups are muted/DND is on).

30

Besides pop up message box, I recommend a notification center, which will show when you move your mouse to the corner or right side of the desktop or press short cut key. Diagram as follows:

notification center.PNG1177×651 6.8 KB

1 Like
31

Don,
yes that’s exactly what I mean when I say notification “shelf”. I made a first attempt at one earlier in the year, then got sidetracked doing the SoftwareUpdater which I thought is more important to have ready for a beta release. Notifications aren’t used much now, but everyone has to do updates :slight_smile:

32

May I scream “feature creep!” here?

I don’t think such fine grained configuration is needed.

33

+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.

34

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
35

Talk about feature creep! :slight_smile:

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 :scream:

36

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)

:slight_smile:

1 Like
37

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

image.png425×523 21.1 KB

4 Likes
38

More progress:

image.png519×624 48.8 KB

2 Likes
39

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.

40

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?