This was discussed couple times before and the reason
this was never added is because of potential misuse of
this by setting extremely high value, making the bubble
virtually sticked to your screen forever. This should be
handled by the server that should do the right thing(tm)
like eg. Plasma does a word count and then with simple
heuristic determines the display time. Regardless of
Plasma however, the server should always have a sensible
default that all apps should follow, therefore this option
was never added and I still think it shouldn't be there
today; I can't see a reason why would you want the
bubble to be displayed for either very short time or very
long time. For anything in between the server default
should be good enough.

I understand the potential of it being misused, even though I don't think we should treat developers as if they didn't know what they are doing. Also, if we want to have a maximum timeout, this is something that should be enforced on the server (ie: Plasma) instead of the client. There will be apps using libnotify or any other lib that can set their timeouts.

The reason I added this is because in KDE Connect we show notifications when there is an incoming "pair request", and I wanted to make the notification stay there for as long as the request is valid. Since the notification is the only way to accept the pair request, I think it results in a bad user experience if the notification disappears before the user can act on it.

There is an alternative solution to my use case: making the notification persistent and manually dismissing it when the request is no longer valid, but I've decided to not implement it this way because some notification servers don't support persistent notifications (eg: Ubuntu Unity).

What do you think?

I see your usecase, but I think there might be better solution overall
and that would involve not actually depending on the notification. As
you say, servers should enforce maximum timeout, Plasma does just
that and there's no safe way to predict what other servers would do.

You could simply create a StatusNotifierItem with "demands-attention"
state, that would cause it to blink, pulse or do whatever the implementation
does. The good thing about this is that this would be animated in the
screen basically forever while not being obtrusive. In Plasma it even
raises a panel that is hidden. It's also fully cross platform and in fact,
it is where the persistent notifications should evolve into (where
persistent is the persistence you're looking for in your usecase). This
would be in addition to the regular notification, not its replacement.
Clicking the SNI would result in the exact same action you'd get from
the notification. Plus, KSNI lives in the KNotification lib, so no new
dependency. How's that?

I don't think indicators are the future of notifications :/

If you have a look at modern systems like Android (which had the luxury of designing a notification system without having to think about legacy), they have nothing like app indicators: they use persistent notifications instead. Gnome has also taken that way [1], so if we make appindicarors a core part of kdeconnect, we will never look native on Gnome... I'm trying to find a different solution.

[1] https://wiki.gnome.org/Design/OS/MessageTray/Compatibility

Well, I would argue that Android is using exactly indicators
which we know as SNIs. It's the same thing - it's an icon in
your top panel and when you pull the panel down, you see
the title, text and available actions. This is _exactly_ what
SNI does, it just so happens that on desktop the representation
is always an icon with context menu. It has title, text and
actions and is often accompanied by a popup notification.

That said, I realize you want to target as broad userbase
as possible, but if Gnome decides to not be cross-desktop
compatible, well screw 'em, their fault. It bothers me that
people always have to find alternate, many times sub-par
solutions and the reason is "Gnome" that never wants to
play along with about anything. But I digress.

I still think having a notification sticked to the screen
with indefinitely-high timeout is not the solution. If only
for the unpredictability of servers. Given the user has to
initiate the pairing and the user is then expected and required
to complete the pairing, how about using some modal way
to confirm the pairing? Like a popup dialog? I mean if the
point of the interaction is to complete the pairing and if
it's imperative that the pairing completes, then just put
it in front of the user square and center to confirm. Raising
the notification timeout for this to me is a workaround
at best.

I agree that just rising the timeout is suboptimal but I still like it better than a modal dialog... Actually, notifications were invented as a way to avoid harassing the user with modal dialogs when apps need attention.

Apart from that, and even if we end up implementing this in a diferent way for KDE Connect, I don't think that KNotification as a framework should hide this feature from the developer. Regardless of the notification server implementation, the underlying protocol that KNotification exposes does allow defining a timeout.

And, about SNIs... It's true that they have a title, text and actions like notifications. But they also happen to be represented in every major desktop (eg: Windows, MacOS, Gnome, Unity and Plasma) as an icon in the system tray that you have to right click to access a context menu with the actions (unlike notifications). Are you sure that's what Android does?

Gnome implements something much more similar to the notification systems nowadays present in Android and iOS (and even Windows and MacOS, which are trying to deprecate their system tray icons), and they do that using the notifications cross-desktop standard. So I wouldn't criticize Gnome for doing their own thing here.

I agree that what Android does makes a lot of sense. What they have is

• a permanent icon in the top bar for each application that still has an open notification - basically an SNI, minus the direct interactivity (which makes sense given that tiny icons are not much fun to interact with on a touchscreen)
• a drawer that shows all notifications that are still valid (plus the same on the lockscreen if enabled)

I have not seen a better notification system anywhere so far, to be honest. It would make perfect sense for me if Plasma did exactly the same, but we'd still need to change a couple of things for that to work:

• We'd need a drawer to show all notifications that are still valid (similar to the notification history that we had in Plasma 4, but with some very important differences, see below)
• We'd need to automatically create an SNI for every application that sends a notification
• Notifications would need to be grouped by application (the notification drawer on iOS shows what a horrible mess you get if you don't do that)
• Notifications would need to be cleaned up by applications when no longer needed (this would need a new API for applications)

This would be perfect, but it would need a whole lot of work from both the desktop environment and the application side.

As long as we can't get there, I agree with Martin that an SNI is a better solution than a permanently shown popup notification, as it attracts attention without covering anything on the screen.

I don't think that KNotification as a framework should hide this feature from the developer.

I, on the other hand, don't see why the developer should need
this feature; as I said before - there's no scenario where the
app should want either really short or really long time on the
screen - this should always be fully up to the shell displaying
the notifications. If you do need to have the notification bubble
on the screen for really long time, then imho that's a wrong
solution to the problem it'd be solving.

And that applies to this case as well. KDE's Bluetooth integration
is solving the same problem (pairing devices) and it uses a dialog,
which imho makes sense, because with notification you're supposed
to inform the user that something has happened and he may or may
not react to that something, while what you're doing requires direct
user interaction and what you're trying to solve is the possible lack
of that direct interaction. So I honestly think that a notification is not
even the right approach here altogether.

they do that using the notifications cross-desktop standard. So I wouldn't criticize Gnome for doing their own thing here.

Oh really? :) Ever wondered why the spec you're referring to
is full of only Gnome's extensions and is hosted on Gnome's
servers? It's because Gnome considers the Galago project,
the actual cross-desktop notifications project, dead. They took
over libnotify and they consider that implementation to be the
canonical upstream for the specification. In other words, Gnome
has full control over that spec, can do what they want and can just
as easily block any of our contributions. Sure, it is based and
backwards-compatible with the cross-desktop standard, but it
stopped being actual cross-desktop standard long time ago.
If you feel like changing that, this would be a good start:
https://bugzilla.gnome.org/show_bug.cgi?id=748145

@colomar: This would be perfect, but it would need a whole lot of work from both the desktop environment and the application side.

It's actually not that hard as far as the last three points go. This
can be fully implemented in the notification's server (ie. Plasma)
and the apps changes would be minimal. I even had a branch
doing exactly that, I just never had the time to finish it. But basically
the idea is - every new notification that arrives to the server is
directly mapped to a KSNI - title to title, text to subtitle, actions
to SNI actions. The lifecycle is a bit tricky (eg. when it is not needed
anymore) but still can be done. I meant to mostly mimic what
Android is doing. The only part remaining to solve is the drawer
that has all the SNIs and their action in some sensible way.

even Windows and Mac have deprecated them in favor of persistent notifications!
Not only it's already implemented, but also it is what every major desktop and phone OS out there already use!

SNIS != those legacy systray icons which were rightfully abolished. Systray icons are shown as long as an application is open (and with that they turn the syrtray into a secondary taskbar which makes no sense)

An SNI may look the same, but the big difference is that it is only shown as long as a notification is present, so when used correctly, they do not clutter your systray with icons but instead give you a good overview of which applications want your attention, without ypu having to open a drawer which shows all notifications.

I admit that what we currently have is more of an interim solution towards what Android does, and in the end SNIs should be merged with persistent notifications to get the full experience, but giving every application control over precisely how long a notification should be shown is not a good step in that direction.

To expand on what Thomas said, SNI is just a specification,
the implementation is fully up to the shells. We chose to
implement it as systray icons, but some innovation there
could take it to much different places. So far nobody has
come with ideas of what that innovation may be, however.

As for Gnome and their standard, well from your point of
view it may all seem great, but with couple years of maintaining
our notification system I will just disagree with you and leave
it there because this is not the place for this conversation.