Notifications preflet changes

I am working on updating the Notifications preflet. It is horribly broken, and I will be adding a “History” feature to view past notifications. This is a stop gap (or maybe a permanent feature) until a notifications shelf can be successfully completed. I have the Revert button working, removed the Apply button (changes are saved immediately now) and temporarily removed the “Notifications” tab until I can figure out what is was meant to do.

I plan to pretty up the list of notifications a bit, add a date/time, maybe an icon for the notification type. My working branch is here (only tested on x86gcc2):
https://github.com/Perelandra0x309/haiku/tree/notifications/src


1 Like

The “notification” tab had two purposes (neither of which was ever implemented):

  • Top part: a list of applications which ever sent notifications, with a checkbox next to them to tell if the notifications should be shown in the notification area, or not.
  • Bottom part, for the selected application, a list of received notifications, with title, date, type (error/warning/info), and wether it was authorized to be displayed by the above mentionned checkbox.

So basically, mostly what you started to redo in the History tab.

I am not convinced by the “preview”. I think just a BColumnListView with the relevant info is enough. It can get all the info added to it: icon, type, title and body text.

Also, the Settings tab clearly needs alignment of the items. Use a BLayoutBuilder with the AddMenuField and AddTextControl methods, it does the right thing :slight_smile: Or maybe use radio buttons for the icon size.

Also, can the window width be adjusted sub-pixel? Why not a slider here? (ranging from 100px to screen width or so)

1 Like

[quote=“PulkoMandy, post:2, topic:6090”]
Top part: a list of applications which ever sent notifications, with a checkbox next to them to tell if the notifications should be shown in the notification area, or not.[/quote]
Ah, a way to turn off notifications per app. Is it possible to draw a functional checkbox control in a column list view?

[quote=“PulkoMandy, post:2, topic:6090”]
I am not convinced by the “preview”. I think just a BColumnListView with the relevant info is enough. It can get all the info added to it: icon, type, title and body text.[/quote]
I have other plans for the list view that don’t conform to the strict column format. You will see :slight_smile:

[quote=“PulkoMandy, post:2, topic:6090”]
Also, the Settings tab clearly needs alignment of the items.[/quote]
Yes i just used what was already there. As I said it needs lots of work.

Sure, sub-pixel rendering on HD monitors is the future :wink: A slider would provide self limiting options. In steps of 100px perhaps?

Thanks for the feedback, I will post back here with updates.

Please take a look at http://growl.info/screenshots and maybe borrow some of the features/settings or design decisions? Also https://support.apple.com/kb/PH25142

Yes I use a Mac as well so am familiar with this, some good design elements there.

Here is a cleaned up settings view and I added a button to reset to default values:

I am thinking of removing the option to choose the mini icon, it looks horrible and it doesn’t really reduce the notification size anyway.

I’m all for removing non-essential options, so if mini icons suck anyway, remove it.
I also prefer the current panel’s checkmark “Enable notifications” instead of the two radio buttons.
How about a slider for window size from “Small” to “Large”. Moving the slider should summon a test notification, so the user has live feedback. In the future choosing different sizes might also adjust the layout, icon size etc., so a live preview would be cool…
The “Hide after” could be a slider, too. 1 to 20 seconds should cover extreme needs, I guess?

Edited to add: The “Enable notifications at startup” can go too. I think it’s expected to get all notifications from the start as long as notifications are enabled at all.

How about “Enable notifications” BBox like in ScreenSaver? I also don’t like “Enable notifications at startup” option, please drop it.
And +1 to what humdinger said.

I found the two checkboxes for “Enable notifications” and “Enable notifications at startup” confusing, I didn’t understand the difference at first. So something had to be done about that. I have been looking at the general style of all the preflets, and for those with Defaults/Revert buttons there are two main styles: Some with a BBox(s) and others without BBox but a BSeparatorView above the buttons. Time and Virtual Memory also have the BBox with checkmark in the label so I think I like that idea.

I do wish there was toggle switch BControl so you could have one control for On/Off, Enable/Disable etc.

There in “SoundRecorder” is this kind of switch. Maybe not exactly…

[quote=“Perelandra0x309, post:8, topic:6090”]
I do wish there was toggle switch BControl so you could have one control for On/Off, Enable/Disable etc.[/quote]

I don’t like this kind of skeuomorphism. I prefer an honest checkbox any day! :slight_smile:

A single “enable notifications” checkbox is the way to go here. No need for that “at startup” thing (it is a leftover from the pre-launch daemon days, I think) and no need for radio buttons for such yes/no options.

I’ve removed the mostly redundant “Enable at startup” checkbox and converted the text controls into sliders which looks and performs much better. Also added controls for potential future features: Do Not Disturb and choosing the location of the notifications.

Also here is a preview of what I would like to do with the History tab when viewing past notifications. I will probably also add a MenuField for a filter to display notification received: Today, Since Yesterday, Last 7 days, Last 30 days, This year, Show All


2 Likes

It looks OK, but I’d do sliders differently:

  1. Width: what if I have 16K display? I think it would be better to change px to %.
  2. Timeout: 60 is too much and makes this slider too crowded. 20, like Humdinger said, is enough.

I like the addition of location change control.

There also can be “Use active monitor” checkbox and “Theme” options.
Preview can be in real place (by clicking some button), not in apps preflet itself.

Won’t the notifications history better located in some “Notifications” deskbar icon than in a window which is, after all, a
"settings" one?

Putting the “location” setting right after the “do not disturb” may let the user think that moving his mouse pointer there will activate the do not disturb feature too, as for disabling screen saver…

Regarding notifications position, why not offer a top and bottom center one, btw?

IMO, it’d be best to have an icon in the Deskbar tray, that offers a context menu with “History” that opens the Notifications panel at the “History” tab. Plus, items for the last 10 recent notifications (the exact number may also be a setting in the prefs).

The “Notification preview” isn’t really a preview, but “Details” of the currently selected notification in the history, I assume.

Instead of the location representation á là Screensaver prefs, the already mentioned live-preview would be better, too. :slight_smile:
Add a button “Notification size and location” that shows a notification in a tab-less window that says:

Notification preferences
Resize and move this notification to set
the default size and location.

long term goal is to have some sort of Notifications “shelf” window where notifications that aren’t dismissed by the user go and can be reviewed. This may make the history unnecessary.

I’d even prefer a history list in the Notification prefs. In the shelf, it’s not always clear that these are old notifications that are shown, and how old they are.
The history list could be ordered by various customizable columns and filtered/grouped with a pop-up menu, as it’s already in your mockup.

A simple popup menu doesn’t seem appropriate for viewing historical notifications, it would need to be more of a popup group view.

I think you’re right. An item to summon the history list should do.

As far as making it draggable, perhaps in a future update. Would need to work out how to deal with differing resolutions in workspaces.

Maybe you can check if there are workspaces with different resolutions around and use the dragged/resized notification window’s coords for all workspaces with the same resolution as the one the user used to drag/resize.
If the user has workspaces with different resolutions, the user will have to adjust the window on all those workspaces separately.

At least, having a “no notification when an app is in full screen mode” setting will be very welcome.

damoklas,
For using a percentage of screen width setting, yes I have considered that and it may be a future change. I will have to experiment and see how that works with different workspaces that are set to different resolutions.

phoudoin,
long term goal is to have some sort of Notifications “shelf” window where notifications that aren’t dismissed by the user go and can be reviewed. This may make the history unnecessary. That’s long term though.

Yes, I wanted to also add top and bottom center locations for notification popups. We may need to extract the screen control class from the Mouse preflet and make it s shared class, or maybe even a full BControl class in the interface kit?

Humdinger,
Deskbar icon definitely in the plans. It may start as just a simple enable/disable Do Not Disturb toggle and quick menu access to settings. A simple popup menu doesn’t seem appropriate for viewing historical notifications, it would need to be more of a popup group view.

I do have it send a sample notification when settings are changed that update the width and timeout so you see real time the change. As far as making it draggable, perhaps in a future update. Would need to work out how to deal with differing resolutions in workspaces.

Suppressing all notification popups (Do not disturb) by request from external apps would be neat. A messaging protocol would need to be developed for the server to manage those requests. The server would still cache notifications received so they could be viewed later. If you manually enabled DND, then another app also requested DND then quit you would still want to keep DND enabled from your original manual request. So multiple requests/cancels for DND need to be tracked. But phoudin, I am not aware of any way to detect that any app is in full screen mode. It would probably need to be up to the app to notify the server that it is requesting DND.