Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request]: Reuse / combine XDG desktop notifications #432

Closed
2 of 4 tasks
nekohayo opened this issue Aug 5, 2023 · 1 comment · Fixed by #439
Closed
2 of 4 tasks

[Request]: Reuse / combine XDG desktop notifications #432

nekohayo opened this issue Aug 5, 2023 · 1 comment · Fixed by #439
Labels
enhancement New feature or request

Comments

@nekohayo
Copy link
Collaborator

nekohayo commented Aug 5, 2023

Describe the request

This is conceptually similar to issue #176, but for the XDG desktop notifications (i.e. notifications bubbles / balloons at the top of the screen in GNOME):

image

...instead of the built-in notifications tab inside Tuba's GUI (which is what #176 is about).

AFAIK, the desktop notifications API lets you modify, cancel, etc. notifications.


For various reasons (avoiding cognitive overload, reducing visual overload on a lockscreen or notifications tray, reducing the amount of stuff the user has to clear, and probably performance too), Tuba should "reuse" / combine notifications. This would be particularly useful when one of your posts unexpectedly goes viral and you want to keep track of its virality without being overwhelmed and without muting it.

There could be one notification for each type (favorite vs boost vs new follower vs new reply). The reply notification could have an action button tied to it to "View reply" if it doesn't already.

So in practice, for example, if you have a hundred people favoriting your post, instead of showing each one of them as a new notification as they come, Tuba should reuse the existing notification for favorites and do something like this (if markup is allowed):

Carlie Rae Jepsen and 458 others ⭐ favorited your post, \n "%s"

...where "Carlie Rae Jepsen" is the latest user to have triggered that "favorited" notification type. The user's avatar would need to be set and replaced everytime (see also #426).

(if you happen to like the drive-by emoji idea... 🚀 or ↗️ or 🔄 or 🔃 or could be boosting, ↩️ / ↪️ could be replies, etc.)

A quick example with notify-send (and alternative wording), but I'm not sure if real notifications are limited to plaintext like that:

image

Implementation Details

  • This should be an option in settings.
  • This should be only available to some fediverse backends. (Include which ones on the above field).
  • This is client-only (and shouldn't sync with the instance).
  • This follows the GNOME HIG.
@GeopJr
Copy link
Owner

GeopJr commented Sep 18, 2023

I made it a setting (disabled by default)

AFAIK, the desktop notifications API lets you modify, cancel, etc. notifications.

I think I have mentioned it in another issue since but just for completeness, the API allows you to either push or withdraw a notification, you can't modify a notification once pushed (the PR dismisses the old notification and pushes a new one)

There could be one notification for each type (favorite vs boost vs new follower vs new reply).

Currently it's only for favorites and boosts (and mentions but that wont work as expected). I don't think new followers should be grouped, the actors are important

The reply notification could have an action button tied to it to "View reply" if it doesn't already.

there's a follow up PR for notification actions

and do something like this (if markup is allowed)

Markup is only available for the notification summary/description unfortunately

(if you happen to like the drive-by emoji idea... 🚀 or ↗️ or 🔄 or 🔃 or could be boosting, ↩️ / ↪️ could be replies, etc.)

I'll avoid it for now as it needs a lot more testing on different environments and fonts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants