kdeconnect-kde

History

Àlex Fiestas dbea3171bd Make kdeconnect core compile without KDELibs4Support This meant to add a lot of dependencies to each plugin since we had KDELibs4support as PUBLIC link meaning that anything linking against kdeconnectcore was linking at the same time to mostly all frameworks. Now each plugin has more or less its dependencies in the CMake some still depend on KDELibs4Support. For the mousepad plugin I needed to add a fixX11.h file that basically undefines/defines again some stuff xlib has that conflcits with normal C++ and Qt. Before it was not conflicting because some lib within KDELibs4Support was including this file, but now we have to do it ourselves.		2014-09-22 02:40:51 +02:00
..
CMakeLists.txt	Make kdeconnect core compile without KDELibs4Support	2014-09-22 02:40:51 +02:00
kdeconnect_notifications.desktop	Document in the desktop files the outgoing types for the plugins	2014-06-14 20:35:00 +02:00
notification.cpp	Port Notifications from kDebug to qCDebug	2014-09-22 00:45:06 +02:00
notification.h	Move the plugins into a different top-ĺevel directory	2014-06-14 16:34:11 +02:00
notification_debug.h	Port Notifications from kDebug to qCDebug	2014-09-22 00:45:06 +02:00
notificationsdbusinterface.cpp	Port Notifications from kDebug to qCDebug	2014-09-22 00:45:06 +02:00
notificationsdbusinterface.h	Fixed notifications not being appearing in the model nor in the plasmoid	2014-07-01 01:26:07 +02:00
notificationsplugin.cpp	Make kdeconnect core compile without KDELibs4Support	2014-09-22 02:40:51 +02:00
notificationsplugin.h	Move the plugins into a different top-ĺevel directory	2014-06-14 16:34:11 +02:00
README	Move the plugins into a different top-ĺevel directory	2014-06-14 16:34:11 +02:00

README

This plugin listens to packages with type "kdeconnect.notification" that will
contain all the information of the other device notifications.

The other device will report us every notification that is created or dismissed,
so we can keep in sync a local list of notifications.

At the beginning we can request the already existing notifications by sending a
package with the boolean "request" set to true.

The received packages will contain the following fields:

"id" (string): A unique notification id.
"appName" (string): The app that generated the notification
"ticker" (string): The title or headline of the notification.
"isClearable" (boolean): True if we can request to dismiss the notification.
"isCancel" (boolean): True if the notification was dismissed in the peer device.
"requestAnswer" (boolean): True if this is an answer to a "request" package.

Additionally the package can contain a payload with the icon of the notification
in PNG format.

The content of these fields is used to display the notifications to the user.
Note that if we receive a second notification with the same "id", we should
update the existent notification instead of creating a new one.

If the user dismisses a notification from this device, we have to request the
other device to remove it. This is done by sending a package with the fields
"id" set to the id of the notification we want to dismiss and a boolean "cancel"
set to true. The other device will answer with a notification package with
"isCancel" set to true when it is dismissed.