Inoki added a comment.
In D22365#532294 <https://phabricator.kde.org/D22365#532294>, @rjvbb wrote: > 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). Yeah, you're right that we should check system version for back-compatibility. AFAIU, we can check it before the creation of notification backend instance, if not compatible, use the old implementation, right? I don't know XCB QPA stuff. Investigating then... REVISION DETAIL https://phabricator.kde.org/D22365 To: Inoki, rjvbb, nicolasfella Cc: nicolasfella, broulik, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
