Differentiate between "new" and "read" notifications

[bd-g]

My problem I often read my notifications and don't want to delete them yet (so I don't forget to act on them lol), but don't want them showing up in the same way as all "new" notifications. For example, I receive an email, I open swaync and see the notification, I want the notification to stick around, but when I close swaync I don't want a highlighted mark saying I still have notifications.

Describe the solution you'd like Two main steps here

1. I would like there to be some sort of metadata on notifications to define when they've been "read". In my case, if I have opened swaync and close it since this notification appeared, I want that notification to be "read". Versus a notification that has been generated after the last time I toggled the notification center, it is "new". Could maybe add options to notification center to filter by read status in addition to filtering by time of notification.
2. I would like swaync-client -swb to differentiate between read and new notifications. This would allow me to set different icons on waybar. For example, right now, it only tells me I have 3 notifications, but if I've already "read" all 3 I want to display a different icon than if some of the notifications are new. The below output is an example of what I want swaync-client -swb to output if I had two "read" notifications, and then the new output if I received an additional notification.

{"text": "2", "alt": "notification", "tooltip": "2 Notifications", "class": "notification"}
***in background, a third notification occurs***
{"text": "3", "alt": "notification-new", "tooltip": "3 Notifications (1 New)", "class": ["notification", "notification-new"]}

Describe alternatives you've considered Tried messing with waybar by itself, but the data output by swaync is too coarse to be able to do this.

[bd-g]

I wanted to write a Pull Request myself for this, but I've never worked in Vala and that would be a learning curve, so I have to put this on the back burner. For someone familiar with Vala, I don't think this is too bad to implement?

[ErikReider]

This would be pretty easy to add. The only difficult thing would be to actually know which notifications have been read. The easy route would be to mark all notifications as "read", even the ones that aren't visible due to scroll. That wouldn't be optimal though...

The best way of doing this would be to somehow only mark the visible notifications as visible. Not really sure if that's possible in GTK though so help would be really appreciated! :)

[bd-g]

The answer by Michy here (https://stackoverflow.com/questions/6903170/auto-scroll-a-gtkscrolledwindow) seems to suggest it's possible.

Taking the general principles from C to Vala, I think it would just involve getting the coordinates of the parent widget (maybe the scrollable interface or the list box within it), and seeing if the coordinates of the child are within it.

[tukusejssirs]

How about no automatic marking notifications as read? All notifications would be unread unless the user (select one or more as you see fit):

• clicks on a notification (basically, it would remove it);
• toggles the read/unread state using a keyboard shortcut or a dedicated button like a small cicle: full circle for unread notifications; empty cicle for read notifications).

[bd-g]

How about no automatic marking notifications as read? All notifications would be unread unless the user (select one or more as you see fit):

• clicks on a notification (basically, it would remove it);

• toggles the read/unread state using a keyboard shortcut or a dedicated button like a small cicle: full circle for unread notifications; empty cicle for read notifications).

I'd like this configurable - I could see a use case for both, but functionality to automatically read notifications would be nice.

Or, introduce three states - new, seen, and read. Seen would depend on whether it's been visible in the control center, and read is when it's been toggled as read by the user?

[tukusejssirs]

If we want to create a list of all possible states (like in a finite state machine), I’d say we should use these states (ordered list):

• new;
• seen;
• read;
• dismissed/closed;
• clicked (an action was triggered):
  • this one could be handled separately, maybe including the action that was triggered (a notification was clicked, action button x was clicked);
• [possibly] archived/saved.

Now, the last two would be nice to have when we store the notifications in a DB in order to retrieve them later (like after a reboot; see #163). The user should be able to do some CRUD operations on the notifications basically; actually only these operations:

• toggle read/unread (or read/seen) state;
• archive/save a notification:
  • while all unread (new + seen) messages should be re-notified after a reboot/re-login, archived messages should not be notified, but they should be accessible;
• remove a notification (no way to recover it).

All read, non-archived messages older than x days (user-configurable time) should be automatically purged from database.

[bd-g]

I like this direction, do you know of current work to store notifications in a DB, or just future proofing?

[tukusejssirs]

I like this direction, do you know of current work to store notifications in a DB, or just future proofing?

@bd-g, I have no info if anyone works on #163, I’ve just wanted to connect the two issues and tell my opinion. :wink: