In case no application name is set but we found a service, use the service name.
Also prefer the service name when the application name just looks like the desktop
entry, e.g. VLC just sets "vlc" as application name, which we would then override
to "VLC media player" from the vlc.desktop we might have found.
This is actually mostly just preparation for should we add a look up of the desktop
entry through the process CGroup.
We do this sometimes, but not consistenly.
The benefit is twofold.
First it improves the diff when adding new values since no existing line needs to be touched.
Second it prevents clang-format from collapsing the definition into a single line, which is undesired for large enums.
This changes the displayed destination of a file operation in the summary
to be relative to the closest user's place, similar to how the KUrlNavigator
(address bar) does it in Dolphin, for example:
* /tmp: Root/tmp
* /home/user/Documents: Documents
* /home/user/Documents/foo/bar: Documents/foo/bar
* ftp://example.com/var/www/clients/user/blog/uploads: My Blog/uploads
* sftp://192.168.0.123/home/user/stuff/kf5/plasma-workspace: Build Server/stuff/kf5/plasma-workspace
Especially for remote locations the user has bookmarked this can tremendously
clean up the displayed address, showing a nice name rather than the full URL.
The other logic about showing local paths and replacement of $HOME by tilde has been
removed as both Root and Home are default places that are likely to be present.
This unit is neutral, it doesn't distinguish between e.g. file and dirs,
just counting items. Useful in e.g. notifications of batch rename jobs.
CCBUG: 422098
This enables some basic grouping when pointing a list at the group parents instead of the individual child elements.
Effectively unused right now (popups don't group and history only shows the application name for sections)
but this is in preparation for being able to have groups in the popup as well.
Differential Revision: https://phabricator.kde.org/D27130
Notification spec says, when replacing a notification:
> The server must atomically (ie with no flicker or other visual cues) replace the given notification with this one.
Notifications shifting about is a "visual cue".
Differential Revision: https://phabricator.kde.org/D29771
WatchedNotificationsModel is a unstable API and does not provide any
API/ABI gurantee, look and feel developers or application developers
should not use this API for time being.
Summary: This allows one to subscribe to notifications from notification server.
Test Plan:
tested using very simple QML
```
import QtQuick 2.0
import org.kde.notificationmanager 1.1 as Notifications
...
Notifications.NotificationWatchedModel {
id: model
}
```
Reviewers: #plasma, broulik, davidedmundson
Reviewed By: #plasma, broulik
Subscribers: nicolasfella, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28509
Apparently by default it only considers "out of range" indices invalid but an invalid one as valid.
CCBUG: 418347
Differential Revision: https://phabricator.kde.org/D29297
Summary: Some applications, e.g. pamac, don't send an app_name, which is legal according to the fd.o spec. In this case try to read it from the desktop file before falling back to the process name.
Test Plan: I get a better appname for pamac notifications now
Reviewers: #plasma, broulik, mart
Reviewed By: #plasma, mart
Subscribers: crossi, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D27786
QML needs it on the model it uses (Notifications) where they used to be but GammaRay seems to be taking them from the source (NotificationsModel).
This has both models (and jobs model) return the roleNames() and moves them to Utils so they're shared.
Differential Revision: https://phabricator.kde.org/D28657
This ensures that newer notification popups don't push old ones out.
Some applications are notorious for spamming the user which right now results in a firework
of notification popups. With this patch only the number that fits on screen is displayed and
everything beyond that is off screen until there's enough room for new popups which are
then gradually lowered.
It also reduces the likelihood of the notification the user is interacting with being shifted
away by an incoming notification. Furthermore, since notifications that are off screen will
have their timeout reset, it can happen that you have a bunch of recent notifications at the
bottom but then get some old ones that were off screen sliding back in because some middle ones
have expired already, leading to awkward results.
Notification scoring (e.g. critical before normal) is untouched, so a "battery is critical" notification
will show up even if it's still chugging through the backlog of browser notifications.
Differential Revision: https://phabricator.kde.org/D28646
Allows to control the behavior of those applications rather than flat-out ignoring them.
Adjust default configuration to blacklist them, though.
Differential Revision: https://phabricator.kde.org/D26160
This adds a quick reply feature with a text field inline in the notification popup.
An action named "inline-reply" will spawn the text field and a NotificationReplied signal is emitted then.
There's additional kde hints for changing the placeholder text (defaults to "Type a reply..."),
submit button text (defaults to "Send") and submit button icon name (defaults to "document-send",
that paper aeroplane icon).
An application could have multiple inhibitions. Release all of them when the service unregisters (process dies).
Differential Revision: https://phabricator.kde.org/D26125
This can be useful for notifications that confirm direct user interaction, such as successful Bluetooth pairing,
Screenshot creation, or plasmoid removal.
It only overrules filtering based on urgency, disabling notifications for that application altogether will still hide them.
Such a notification also won't increase the unread counter as it can be assumed when they do something, e.g. click on "Pair",
they will notice that the pairing progress dialog went away and a confirmation notification is shown.
Differential Revision: https://phabricator.kde.org/D25935
It can be used to query information about the current notification server (vendor, name, version, notification spec version).
This will be used by the plasmoid and KCM to indicate when notifications are currently unavailable or provided by a
different notification service from Plasma. Also notify valid changing at runtime when ownership is lost.
Differential Revision: https://phabricator.kde.org/D25772
Fixes erroneously enabling do not disturb mode in some situations when having screens mirrored and then closing the lid.
You'll have two overlapping screens but one of them is disabled so should be ignored.
Depending on the order of outputs this may or may not happen (which is why I didn't notice earlier when I tested with my new laptop).
CHANGELOG: Fixed erroneously entering do not disturb mode when there are overlapping *disabled* screens
Differential Revision: https://phabricator.kde.org/D24679
The inhibition handling (e.g. combining time-based, screen mirrored, etc) is done inside the applet.
The Server knows nothing about it and only reports Inhibited as true when an external application
requested one, not when the user enabled it in the applet.
This patch exposes the NotificationManager.Server as singleton QML type and adds a way for the
applet to tell it the effective inhibition state.
Exposing the server to QML could also be used in the future to provide better error reporting
to the user when the service isn't running and/or owned by someone else (e.g. Dunst)
Differential Revision: https://phabricator.kde.org/D24486
A job instance is created as soon as the job starts but it might not be shown to the user right away or at all.
JobPrivate::prettyDestUrl() already creates the KFilePlacesModel if needed, no need to do it in the constructor.
Differential Revision: https://phabricator.kde.org/D23983
Currently, a notification is considered "unread" when it was created or updated after the last time the user opened the history.
To alleviate this, when the notification popup is hovered, e.g. because the user wanted to drag an image out, select some text,
or open the "More" menu, it is considered read. It will still end up in the history but will not needlessly show the "unread notification" bell icon.
Moreover, job finished notifications are always considered read, as they are either from long-standing jobs which the user is likely aware of,
or confirmation of short tasks the user doesn't need explicit confirmation about. For example, extracting an archive in Dolphin,
I get an "Extracting (Finished)" but I don't want to explicitly acknowledge that notification because I can just enter the folder that was just created in Dolphin.
This surely doesn't fix the underlying problem of notification expiration and history, and the user might just interact wiht some
tray icons or the clock and not actually deal with the notification popup but this is imho an acceptable stopgap until a proper
solution is found, which won't happen in time for Plasma 5.17 anyway.
Differential Revision: https://phabricator.kde.org/D23977
Summary:
==1408== Conditional jump or move depends on uninitialised value(s)
==1408== at 0x1F0D8A6D:
NotificationManager::NotificationGroupCollapsingProxyModel::setLimit(int)
(src/kde/workspace/plasma-workspace/libnotificationmanager/notificationgroupcollapsingproxymodel.cpp:112)
==1408== by 0x1F0BA091:
NotificationManager::Notifications::Private::initProxyModels()
(src/kde/workspace/plasma-workspace/libnotificationmanager/notifications.cpp:227)
==1408== by 0x1F0BBC75:
NotificationManager::Notifications::setGroupMode(NotificationManager::Notifications::GroupMode)
(src/kde/workspace/plasma-workspace/libnotificationmanager/notifications.cpp:584)
==1408== by 0x1F09F7B2:
NotificationManager::Notifications::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**) (moc_notifications.cpp:668)
Practical impact is limited as every user has to call setLimit anyway
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23683
This makes it group notifications of different "origins" not group together,
e.g. FooApp notifications from phone A won't be grouped together with FooApp notifications from phone B.
Also, email notifications from different accounts wouldn't be grouped together.
Finally, show the origin in the grouped header.
Differential Revision: https://phabricator.kde.org/D23583
This implements a new JobViewV3 which uses extensible variant maps rather than individual function calls,
allowing for compression of calls and extensibility.
The new API uses infoMessage correctly as a state message, e.g. "Connecting to host" rather than mixing it with the "Copying..." heading.
It also supports an "immediate" flag that the caller can use to indicate progress should be immediately shown,
so in cases where the user is likely to want to use the file afterwards (e.g. download through p-b-i or receiving a file
through KDE Connect) a job popup is shown even for small/short transfers.
Differential Revision: https://phabricator.kde.org/D23293
Marco Martin
Kai Uwe Broulik
Nicolas Fella
Laurent Montel
Ahmad Samir
Bhushan Shah
Cyril Rossi
Yuri Chornoivan
David Edmundson