> 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel