GitLab

When new context menu is beeing set we should notify about it.
It is possible that the menu is cached on the client side and the menu items ids are the same.

This signal not part of the official standard but already used by Qt
(starting from Qt 5.11).

CCBUG: 383202

KPassivePopup is old and quite broken visually. KNotification is
superior in pretty much every way

Otherwise a backend may deref and thus delete a notification before
another backend got a chance to ref it.

This happens when a backend calls finish from notify which is done e.g.
in notifybyaudio

In C++20 there are new classes that have member functions named emit().
c.f.:
https://lists.qt-project.org/pipermail/development/2020-February/038812.html
https://en.cppreference.com/w/cpp/io/basic_osyncstream/emit

GIT_SILENT

Currently the notification ids are created/tracked in
notificationmanager. Ids are only assigned after notify has been called.
This has lead to lots of confusion and ugly workarounds like
!19.

By moving the handling inside the KNotification class and assigning a
good id at construction we ensure that we have one from the start.

Having a notification id of -1 is still a relevant special state at the
end of a notification's lifetime. That should be disentangled in a
future patch.

If a notification is in the pending queue it is not yet in the
notifications map. When the notification is then closed we will hit the early return because the id wasn't found.

We need to still remove it from the queue so move the relevant block up.

If the notification is not removed from the queue it will stay as a
dangling pointer and blow up when the capabilities are queried and we
reemit the notification.

BUG: 423757

notifications uses DBus ids as keys, comparing that to
notification->id(), which is a different kind of id, doesn't make sense

NO_CHANGELOG

The purpose of this is twofold. It serves as a code example, but most importantly it can be used to test changes in KNotifications. It is currently very basic, but can be expanded in the future

Summary:
Various improvements. Better examples, updated coding style for the examples, removed some obsolete things.

There's room for more improvements, but this is a first step

Reviewers: #frameworks, broulik, jucato, cblack

Subscribers: cblack, class, apol, kde-frameworks-devel

Tags: #frameworks

Maniphest Tasks: T12709

Differential Revision: https://phabricator.kde.org/D26918

Passing the parent widget to the Q*Layout ctor sets that layout as the
log-level layout for that widget

Not persistent doesn not imply transient, that is an unrelated property.

There are vaild use cases for transient notifications, but it shouldn't
be set unconditionally.

BUG: 422042

Bug: 415215

NO_CHANGELOG

They are the same on Linux (but DataLocation is deprecated). On Windows this enables the use of the roaming path.

NO_CHANGELOG

In case the notification server sends invalid actions don't forward them to the application.

For example LXDE sends ActionInvoked for the default action even when no default action has been declared.

BUG: 427717

Stuff not supported in this version of backend:-

* No Action Center support
* No notification update support

Document the need for a DesktopEntry field to make the
application's notifications appear in the notification history.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"