Review Request 115695: Rework KNotification to work without KNotify daemon

[Nicolás Alvarez]

> On Feb. 19, 2014, 7:06 a.m., Aleix Pol Gonzalez wrote:
> > src/notifybypopupgrowl.h, line 37
> > <https://git.reviewboard.kde.org/r/115695/diff/3/?file=243849#file243849line37>
> >
> >     Is growl still the thing for MacOS X?
> 
> Martin Klapetek wrote:
>     I'm not sure to be honest...I've heard they reworked it and I've no idea if they still support Growl...also Growl used to be on Windows afair, but have no idea about it there either...I'd personally be in favor of dropping this as I have no way to test

OS X 10.8 added a built-in notification system.


- Nicolás


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115695/#review50197
-----------------------------------------------------------


On Feb. 13, 2014, 7:14 a.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115695/
> -----------------------------------------------------------
> 
> (Updated Feb. 13, 2014, 7:14 a.m.)
> 
> 
> Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela.
> 
> 
> Repository: knotifications
> 
> 
> Description
> -------
> 
> This patch merges KNotify daemon into KNotificationManager to have less daemons running and less dbus traffic. The patch is not yet finished (and for now it's full of QDebugs, that will all be removed and FIXMEs to indicate what needs doing), but as the Alpha2 is quite soon, I'd like to start the general review asap so some more changes can be done if needed.
> 
> Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them the notification directly. KNotifyConfig was repurposed a bit, now it serves mostly just as the .notifyrc wrapper, all the rest is reused from the KNotification object. There are some changes in the KNotification API - id() and appName() are now exposed to public and "slotReceivedId(int)" is now also public so that KNotificationManager can directly give it an id. I'd like to rename this and make it a non-slot. It's not the DBus/Galago server ID anymore, that is handled in NotifyByPopup which is responsible for communicating with the galago server (all the methods there were renamed to actually have *galago* in the name so it's clear), therefore the mapping of DBus/Galago Server ids is managed only there as it is actually only needed here. KNotitification::id() is assigned by the KNotificationManager and it's a simple increasing counter.
> 
> The UI/Plasmoid changes will come next - basically the plan is to put only the "Persistent" notifications in the notifications history.
> 
> 
> Diffs
> -----
> 
>   src/knotifyconfig.h PRE-CREATION 
>   src/knotifyconfig.cpp PRE-CREATION 
>   src/knotifyplugin.h PRE-CREATION 
>   src/knotifyplugin.cpp PRE-CREATION 
>   src/notifybypopup.h PRE-CREATION 
>   src/notifybypopup.cpp PRE-CREATION 
>   src/notifybypopupgrowl.h PRE-CREATION 
>   src/notifybypopupgrowl.cpp PRE-CREATION 
>   CMakeLists.txt 63ebf71 
>   src/CMakeLists.txt a81b913 
>   src/knotification.h 00554ba 
>   src/knotification.cpp 5d7405b 
>   src/knotificationmanager.cpp a4d0dfa 
>   src/knotificationmanager_p.h 81d962d 
> 
> Diff: https://git.reviewboard.kde.org/r/115695/diff/
> 
> 
> Testing
> -------
> 
> Works perfectly with both plasma notifications and kpassivepopup.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140219/4dca5dae/attachment-0001.html>