Change Details

Introduce libnotification A library revolving around notifications. This serves as a replacement for the notification dataengine and logic inside the notification plasmoid. Its architecture is inspired by libtaskmanager. There's three main classes: * **Notifications**: The main model providing notifications and jobs combined with fine-grained filter, grouping, and sorting capabilities. This is what you want to use for showing notifications. The model itself is very generic and doesn't make any assumptions on representation (e.g. popup or history) and it is up to the user to set the appropriate filters and other properties based on the user's preferences and desired presentation. * **Settings**: This encapsulates all global settings related to notifications. It will be used by the KCM to write into as well e.g. task manager and notification plasmoid to read settings from. It basically presents a "current state" in which the notification system is in, that includes do not disturb settings/mode. * **Server**: This class handles the DBus stuff and acts as a dumb proxy between DBus and the consumer, e.g. the `NotificationModel` or the old dataengine. The old dataengine is wired up to the new `Server` for compatibility. The grouping stuff in there has been dropped, the old plasmoid should otherwise continue to work as normal. The dataengine inhibition feature used by plasma-nm is defunct now, not sure how this could be implemented in the new system as the `Server` knows nothing about inhibitions, it's all filtered in the models.

Introduce libnotification A library revolving around notifications. This serves as a replacement for the notification dataengine and logic inside the notification plasmoid. Its architecture is inspired by libtaskmanager. There's three main classes: * **Notifications**: The main model providing notifications and jobs combined with fine-grained filter, grouping, and sorting capabilities. This is what you want to use for showing notifications. The model itself is very generic and doesn't make any assumptions on representation (e.g. popup or history) and it is up to the user to set the appropriate filters and other properties based on the user's preferences and desired presentation. * **Settings**: This encapsulates all global settings related to notifications. It will be used by the KCM to write into as well e.g. task manager and notification plasmoid to read settings from. It basically presents a "current state" in which the notification system is in, that includes do not disturb settings/mode. * **Server**: This class handles the DBus stuff and acts as a dumb proxy between DBus and the consumer, e.g. the `NotificationModel` or the old dataengine.

Introduce libnotification A library revolving around notifications. This serves as a replacement for the notification dataengine and logic inside the notification plasmoid. Its architecture is inspired by libtaskmanager. There's three main classes: * **Notifications**: The main model providing notifications and jobs combined with fine-grained filter, grouping, and sorting capabilities. This is what you want to use for showing notifications. The model itself is very generic and doesn't make any assumptions on representation (e.g. popup or history) and it is up to the user to set the appropriate filters and other properties based on the user's preferences and desired presentation. * **Settings**: This encapsulates all global settings related to notifications. It will be used by the KCM to write into as well e.g. task manager and notification plasmoid to read settings from. It basically presents a "current state" in which the notification system is in, that includes do not disturb settings/mode. * **Server**: This class handles the DBus stuff and acts as a dumb proxy between DBus and the consumer, e.g. the `NotificationModel` or the old dataengine. The old dataengine is wired up to the new `Server` for compatibility. The grouping stuff in there has been dropped, the old plasmoid should otherwise continue to work as normal. The dataengine inhibition feature used by plasma-nm is defunct now, not sure how this could be implemented in the new system as the `Server` knows nothing about inhibitions, it's all filtered in the models.