Notification badges on app icons

[Levi-Lesches]

I was reading through the v2 proposal at #983 and saw this:

Things we don't want

We don't want API for showing "n unseen notifications" badges on app icons.

I didn't see this discussed anywhere in that thread -- but why not? Badges are supported on every other platform: Windows, MacOS, iOS, Android, and even Web. Googling "Linux app badges" shows bug reports (mostly about Discord) from users concerned that they can't see their badges, so I'd argue it's a feature people want. Specifically, I'm contributing to the flutter_local_notifications plugin where this feature has been requested.

[Mikenux]

Thanks for opening a specific discussion!

Here are two problems of custom badges that I experienced:

• Sometimes I don’t know what the badge is corresponding to.
• When I guess what the badge is possibly corresponding to, apps do not remove or update it. For example, it happens with the Google Store on Android.

For these reasons, conditioning badges to notifications can resolve those if the UX is there, as those will be controlled by the system.

However, I understand that people want badges that are just not a count of all notifications. So, my proposal is to keep badges conditioned to the use of notifications while allowing to link them to a notification category. The badge will still be a count of these notifications. It does not allow to have a badge of unread messages taking into account unread messages prior to an app installation, but it sounds to me like a good compromise.

[Mikenux]

What I mean is that I don't want end users to have to manually set up an equivalent to KWin Window Rules just so that the notifications that update the badge are hidden but the other notifications pop up like normal if the users turn them on.

Sure. That’s the reason of the "group".

And yes, the notification can be updated if you only use one notification.

[ssokolow]

To me, it still feels like you're trying to force a round peg into a square hole.

EDIT: Sure, have a setBadge(count: int, reason: str) if you must, but don't try to mush together notifications and application-definable badging.

EDIT: If the desktop wants to show a count of unread notifications as a badge, it doesn't need help to do it (aside from ensuring it knows which windows are associated with which notifications) and, if an application wants to display a number in a badge, it's counter-productive to have it dancing around the normal notification system to achieve that goal.

[Mikenux]

Stop. I don’t have time to constantly play with you. You seems to be ok, then no coming with multiple edits, then be ok, etc. etc. I don’t want to come back into the situation in the neighboring file issue.

[ssokolow]

I understood "Stop. I don’t have time to constantly play with you." but the rest of what you said is a bit incoherent.

Either way, you have my view on things and I apologize for the times when I misunderstood your earlier on.

We can stop here and I'll trust that, if the end result is a portal that doesn't meet my needs, I can just stay with the old APIs, like when PCSX2 got fed up with the delays and politicking around Wayland APIs and started publishing Flatpaks with --socket=wayland removed and AppImages locked to X11 via build-time preferences unless users set the I_WANT_A_BROKEN_WAYLAND_UI environment variable in order to meet their standards for quality control.

[Mikenux]

My problem is not that you misunderstood something. That’s the multiple comments that come with edits that lengthen those, and the examples that are either too long or even unrelated. For example, in your comment here, mentioning the Wayland situation with PCSX2 is unuseful. The thing is I had to read your long comments to see if there is something useful in it. That’s not easy to process, especially when you come frequently with something new. Maybe it's your way of expressing things, but be aware that for others, it can be cumbersome to process.

[JakobDev]

This is a feature that already exist in Linux. It is not part of the Portals and was introduced by Canonical for the Unity Desktop. That's why it's called Unity Launcher API. Today it's supported by a few Desktops (most notably KDE) and a few Application Launchers. You can use this API by simply emitting a DBus Signal. Here's how you do it using a cli. It is already used by a lot of Programs including Element and Discord.

While I agree that it should be moved to a Portal for better discoverability and to make it more official, it is a already existing Feature that could be used by Linux Desktop if they want it.

[ssokolow]

Fair. I knew the Unity Launcher API could do Win7-style progress-bar-in-taskbar shenanigans, but didn't know anything else it was capable of because, as a developer, I lost interest as soon as I discovered that it only works if it indirects through a .desktop file and I considered that an unacceptable complication in my cd ~/src/project; ./dev_run.sh development workflow. (Just as incompatible with cargo run/uv run/etc. in an uninstalled git checkout as with an appimaged-less Appimage.)

That's actually one of the reasons I considered the lack of what became xdg-toplevel-icon to be a blocker on officially supporting Wayland instead of X11 in my own creations. (Granted, at the moment, the main thing I'm known for is fundamentally tied to X11 anyway since it's using X11's lack of a security model to replicate the "monkey-patch keyboard-driven window tiling into any window manager" trick that WinSplit Revolution does on Windows.)

[Mikenux]

For setting a custom count: count + object. Examples: 3 new messages, 5 unread news. The system can precede this with "You have."