| mart | |
| colomar |
| Plasma |
This uses the feature introduced here [1] on KNotifications, so default
actions don't appear as a regular action button. Instead, they are
activated by clicking on the notification itself.
If the default action is not set, it uses the previous behavior of close
on click.
This changes both the notification popup and the notifications inside the
plasmoid.
Manual testing.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
-1, I don't want to keep thinking "am I now going to close the notification or execute an action" everytime I'm about to click the notification popup.
I want my workspace to have predictable behavior that doesn't get in my way.
If you just want to close then you have the big X, no?
Actually, up until this patch, I never expected that clicking would close the notification.
If you just want to close then you have the big X, no?
That doesn't change the fact that the behavior of clicking the popup itself would change in an unpredictable way. One time it's close and other times it's execute and there's no visual way of telling when it will do what. That's the actual problem.
That doesn't change the fact that the behavior of clicking the popup itself would change in an unpredictable way. One time it's close and other times it's execute and there's no visual way of telling when it will do what. That's the actual problem.
I have never considered unpredictable on Android that when I press the "new e-mail" notification I get the e-mail client with the new e-mail.
If we implement executing the default action on click, then if there is no default action, a click should _not_ close the notification (to avoid unpredictable behavior).
Is there a way for the shell / window manager to tie a notification to a window (if there is one)? If so and there is no default action, it should just raise the corresponding window. If that is not possible, nothing should happen then.
How useful the whole thing is depends on whether the majority of apps does define a default action. If not, having a click close the notification is more useful then having it do nothing in most cases.
It looks like the explanation on the commit message lead to confusion about the "two different behaviours" thing. Let me explain it a bit more.
First of all, note that notifications always close when you click them, in both cases. The notification disappears because it already fulfilled it purpose of notifying the user. Of course, right now notifications never have a default action, so closing is all they do.
With the addition of the default action, notifications can do something more than "being acknowledged": they can execute some code. But after doing so, they also close. The behaviour is consistent: notifications that the users has noticed and reacted to go away, as they already accomplished their goal.
I think every other notification system that you might have used follows the same principles, even though in most cases there is always a default action set.
I agree some users might think: "I clicked this notification hoping it would open the app, but it didn't, and now I have to open the app myself". For notifications where it makes sense to launch the app (eg: IRC messages), I think we should encourage app developers to always set a default action to do that. Unfortunately, there has to be a transition period until this happens.
From the point of view of the notification, though, I think that making them go away is what makes more sense after the user has already noticed them and by clicking them they communicate to the notification that its goal is fulfilled.
If after this explanation, you still think the same way, the alternative is to make notifications that don't have a default action only go away by clicking the "X" button, but then I think it will be more inconsistent: if I click a notification as a way of acknowledging it, sometimes it will go away (after executing the default action), and other times it will stay there.
I have never considered unpredictable on Android that when I press the "new e-mail" notification I get the e-mail client with the new e-mail.
On Android, you close the notification by swiping to a side. On Plasma, you close the notification by clicking it. On Android, you execute action by tapping the notification. Now with this, on Plasma, you execute the action by also clicking it. In other words, the same mouse gesture is used to either close the notification OR execute an action and you have no way of knowing which one will happen. See the problem now? You cannot really compare these two because Android has clearly defined behavior with unambiguous gestures.
With the addition of the default action, notifications can do something more than "being acknowledged": they can execute some code. But after doing so, they also close. The behaviour is consistent: notifications that the users has noticed and reacted to go away, as they already accomplished their goal.
That's what I'm against - clicking the popup currently only closes the notification. I want to be sure it _only_ closes the notification. I don't want to play a guess game every time a popup shows up - "will my click _only_ close it or will this now open the mail window (which I don't want)"? Therefore the behavior is _not_ consistent. It is closing vs executing action AND closing. And the user has no idea when will happen what.
So as Thomas says, the closing-on-click either needs to go away or just make the default action a button. We've always had buttons in the notifications for actions, this would only be consistent with what the users have learnt in our DE and what they expect. I don't see a reason to change that, especially because the button is labeled and it's always clear which action is going to happen.
Think of Spectacle - you take a screenshot, you see a notification that it was saved. You click the notification with default action - what do you think it's going to happen? Is the image going to be opened? Is the file going to be opened in file browser? Will this show a dialog allowing to share the screenshot? This kind of ambiguity makes me think that having a clearly labeled button would be a better option. Even a combo - have a highlighted button which is always on top of the actions list and when you click the popup, you will know it will execute the first/highlighted action. This could work even without a default being set, simply highlight the first action button and clicking the popup could then always execute the first action. So this patch would just ensure that the default action is put on top.
I absolutely *hate* that clicking a notification closes it. I always do that by accident and for closing I *always* use the X button.
I agree that having some sort of visual indication of what clicking the popup will do would be beneficial. But then if we remove "click for close" we'll either trigger the default action or do nothing and close only on X it wouldn't be a "double gesture".
However, since we're conditioned by the way Plasma worked for years to always have a visible action button might be hard to change, especially since it involves a slew of third party apps we can't control and/or will take forever to adapt.
However, since we're conditioned by the way Plasma worked for years to always have a visible action button might be hard to change, especially since it involves a slew of third party apps we can't control and/or will take forever to adapt.
That's not entirely true, in fact here we're implementing a similar behavior as the one on Gnome. We weren't using the default action and we just closed on click.
I think Plasma is the only notification system that does close-on-activate instead of executing some action. Until now it wasn't even possible to add a default action, but now that it is possible I think we all agree this is something good that apps should adopt.
The main problem here seems what to do for apps that don't define a default action. Would everyone be happy if we just do nothing in that case? I would be cool with that if this way we reach a consensus.
This is still a change, though: close-on-activate won't work anymore and you will have to use the X button to dismiss notifications (equivalent to the swipe gesture on Android), but I think it is coherent.
However, those who think that we shouldn't change anything our users are used to might not be happy with that behaviour either. Maybe the UX group can have the final word on this?
I think Plasma is the only notification system that does close-on-activate instead of executing some action
Plasma might also be the only system that uses buttons for actions and I see nothing wrong with that; it's what we've had forever and it works well, there's no reason to copy others when we have a good differentiating factor imho.
Thinking about it a bit more, not doing anything when you click the notification without default action is again a guess game - "will clicking this popup do anything? how do I know?". So I'd say either clearly indicate that clicking the popup will execute an action (maybe different color or some icon somewhere or maybe a whole different popup) or have the click always do something, perhaps just open the app when no action is set. This would however be quite a behavioural change and will most definitely confuse users that are used to close the popup by clicking it. Anyhow, let's make it really clear and unambiguous when will what action do what; users don't like UIs they can't trust.
Since there does not seem a clear "best solution", isn't this something that should be decided on a cross-desktop level?
After all, it's not just about what users expect, but also what app developers can expect to happen with their notifications.
From the cross-desktop Galago spec [1] we implement (well, actually we implement Gnome's extension to it [2], but same thing):
The default action (usually invoked my clicking the notification) should have a key named "default".
It doesn't say it is "mandatory" to invoke that action on click, but IMO it's what makes more sense and what every other desktop does. Consistent cross-desktop behaviour is what is implemented in this patch.
[1] http://www.galago-project.org/specs/notification/0.9/notification-spec-0.9.txt
[2] https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html
Nope: http://imgur.com/a/Tfen4
We are not inventing the wheel here. Current, modern notifications are something that has been established for a while now on every device. Plasma is the only major desktop that hasn't implemented something on the same lines.
KDE applications should define default actions, like Gnome, Windows and Android apps already do. The only issue is that until now it wasn't possible to do so, so we need to catch up.
If the apps don't implement default actions and notifications don't do what the users expects, then I blame the app. The same way an app can implement a button that says "Close" and when clicked it pops up a picture of a cute cat.
Well there you go then. Just implement the default action to be always the top-most button in our actions list and make clicking the popup always execute the first action in the list. That way, if there are buttons, the user will know that clicking the popup will trigger the first action. No buttons means clicking won't do anything.
This is then clearly marked/distinguished, well defined and always predictable behavior, no guess work needed.
I don't think that having two ways to perform the same action is good UX. The user might be confused about why action_X happened if he/she explicitly didn't press the action_X button that was there.
And a real use case: KDE Connect uses notifications with two buttons for pairing requests (Accept and Reject). If I don't click Accept explicitly I don't expect the pairing to be accepted.
Fair enough.
Let's make a step back then. Since you've mentioned "Plasma is the only notification system that does close-on-activate instead of executing some action", can you actually list what happens elsewhere? How is default action implemented in Gnome? What happens when there are regular and a default action? Can you give at least 3 actual examples? Ubuntu's Unity? I think it'd be great if everyone could get better idea and understanding of how others handle this and perhaps then come up with something fitting for Plasma. I'll test how does macOS behave.
GNOME Shell (3.18) does the same as the proposed patch: once clicked the notification runs the default action (if any) and disappears.
Unity (7.4.0, from Ubuntu 16.04 LTS) is a bit crazy: if the notification doesn't have any action and is transient, then it is displayed as a floating balloon. However, if there are any actions or the notification is persistent (timeout==0), then it displays as a dialog instead! On the dialog, pressing "Ok" triggers the default action and pressing "Cancel" dismisses the notification. Also, I've found that Unity's notifications system doesn't declare the "actions" capability on DBus, so KNotifications will never set any action under Unity :/
Windows has two different APIs (the old one from Windows XP and the new one since Windows 8), but essentially it does the same thing as Gnome or Plasma with this patch: if the user clicks the notification it is dismissed and it might run a default action. The new API lets you add additional action buttons (and any arbitrary controls) in addition to the default action. If there is no default action, clicking the popup on the old API just closes the notification, while in the new API it launches the app's main Window (which must be in the Start Menu, otherwise it doesn't let you create notifications lol).
Android: If an app doesn't provide a default action (PendingIntent), then it does nothing on click. It must be dismissed by swiping it away. If there is an action defined, then it launches it and dismisses the notification (even though you can also make your notification persist even after clicked).
iOS: When the users taps on a notification, the app opens and receives a callback. If you don't implement anything there, they your app will just open.
Thanks, that's a nice list. I think real examples using actual native apps would provide better insight (like calendar, low battery or music player notification), but that'd be like a weekend project, so it's ok.
macOS: Clicking a notification popup will in most cases bring up the app with the details - eg. calendar reminder will bring up calendar with the event details opened, f.lux "You're waking up in 8 hours" will bring the settings dialog and low battery notification will do nothing on click.
I'm fine with the proposed behavior then, just that clicking the popup with no action should not do anything. This is however a 180 degrees turn in the behavior, so it should be at least noted in the release notes.
Final +2 decision should be up to Kai and/or Thomas though.
+1 from me, with clicking on a notification that does not define a default action doing nothing
the x is not that big and is significantly more difficult to aim at than the whole notification, with the added penalty that if you miss it, you will trigger the action, without wanting it.
in 99% of the cases, the only interaction one wants to have with a notification, is to get it out of the way.
also -1 on this
so (didn't really want to be the one to put a ship it on this but whatever) let's go with this in master, so is still as early as possible in 5.10 cycle, and let's see how it goes with this with people
I still have to make the change to not close the notification if there is no action. As soon as I change it I will push it. I agree it's good to have this early in master, so we can have feedback and see if we need any tweak before the next release.