Allow installation of new notification categories and dbus configuration files
asked 2016-01-18 22:49:35 +0300
This post is a wiki. Anyone with karma >75 is welcome to improve it.
This was #action for me from last sfos meeting ([0] http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-01-14-14.30.html)
Related github issue: [1] https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/issues/76
As the notifications are now allowed, the notification categories should also be allowed to be written in the assumed location:
/usr/share/lipstick/notificationcategories/
Also the dbus is allowed, and notifications have remoteActions over dbus, the .service and .xml should also be allowed to be written in their assumed locations:
/usr/share/dbus-1/services/
/usr/share/dbus-1/interfaces/
This needs documentation, and some studying which kind of security breaches this could cause, and how the harbour QA would verify/validate these.
Documentation
[3] https://git.merproject.org/mer-core/lipstick/blob/master/doc/src/notifications.dox#L71
After reading [3], afaiu the category files can be omitted, and completely embedded in application by just adding the same hint=value pairs
Security
TBD
Validation
Some suggestions;
File naming for notification categories:
x-harbour.appname.whatfor.conf
x-harbour.appname.whatfor.preview.conf
The notification category can access your own images under /usr/share/harbour-appname/
(Adding custom feedback (sounds, leds) is out of scope here)
File naming for dbus stuff;
com.yourusername.harbour.appname.xml
com.yourusername.harbour.appname.service
Simple example files i used in one of my project:[4] https://github.com/kimmoli/maira/tree/master/config
The introspecting of the dbus interface shall work. Dbus interface shall expose (only) notification user-action callbacks. Service file shall be for same interface as the xml, and only for launching the harbour-appname application.