rjvbb added a comment.
I haven't been able to give this much attention, sorry. After backporting the patch to OS X 10.9 it does work so I presume it'll work even better with the full functionality availability. One thing: it has a hardcoded assumption that the Cocoa notication APIs will always be available and usable - IOW, that the Cocoa QPA plugin will always be the one in use. Of course it's very unlikely to encounter other QPAs in the wild that support full-fledged GUIs but what about the few other cross-platform QPA plugins (minimal and offscreen to name just 2)? Will notifications be disabled upstream of the platform implementation when those are used, for whatever reason? Because if not, the SDK will throw an exception, or (more likely), something will crash because the integration layer returns nullptr for a required platform function. I found that out when a notification was triggered while I was using the XCB QPA (I use Konsole as my X11 terminal emulator under XQuartz, and also do some remote displaying). I haven't looked closely at the implementation but I assume it should not be costly to check the platform name before deciding to use the new Mac notification backend, just as a preparation for possible future changes (Qt don't formally outlaw the XCB QPA, for instance). REVISION DETAIL https://phabricator.kde.org/D22365 To: Inoki, rjvbb, nicolasfella Cc: nicolasfella, broulik, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
