In D29108#655117, @vonreth wrote:

Sounds ok
Craft is now on invent.kde.org so you can use pull requests.

In D23141#648591, @nicolasfella wrote:

What's the status of this?

Landed:
https://cgit.kde.org/craft-blueprints-kde.git/commit/?id=9fed60f84873b998bdce09966c1ae5e01f41c730

Landed:
https://cgit.kde.org/knotifications.git/commit/?id=58caf6ad5b48aa573a6d3b8d3e23e07afce8a03f

Updating with new incoming code.

In D24118#540236, @apol wrote:

Wasn't this landed?

In D22365#538245, @lnj wrote:

There's something for notifications for iOS and macOS here: https://developer.apple.com/documentation/foundation/nsnotification
Would this patch already work on iOS or could a common API for both be used?

(I have no experiences with iOS or macOS, but we (Kaidan) would like to support notifications on iOS in the future.)

In D24118#535345, @vonreth wrote:

hm the bundle name looks ugly....

In 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).

I found 2 libs which are changed and recovery them in command line, it works:

➜  Frameworks install_name_tool -change @executable_path/../Frameworks/qca-qt5.framework/Versions/2.2.0/qca-qt5 @executable_path/../Frameworks/qca-qt5 libkdeconnectcore.1.dylib
➜  Frameworks install_name_tool -change @executable_path/../Frameworks/qca-qt5.framework/Versions/2.2.0/qca-qt5 @executable_path/../Frameworks/qca-qt5 libkdeconnectinterfaces.1.dyli

In D23141#511651, @vonreth wrote:

So libkdeconnectcore links the lib and not the framework?

In D17790#506460, @sredman wrote:

In D17790#506079, @Inoki wrote:

Is this good to ship?

Since there is a dylib duplicated link error caused by qca-qt5 on macOS(when we use Craft to pack KDE Connect with qml files), this will be helpful for all qml apps we have up to now :)

I think at the sprint we decided we didn't want to use OpenSSL. It has licensing problems when using the library directly and using the binary seems like it could lead to problems with multi-platform packaging and with the potential for the command-line flags to change in the future. We talked about looking at GnuTLS but nobody has done that yet.

What problem are you having? It seems weird that you would only be having a problem with QML applications now since there are already several, like the SMS app and the settings app and since none of them use QCA

Since objective-c stuff cannot co-work well with QML, the relevant solution is abandoned.

Is this good to ship?

In my repo, I added a CMakeLists.txt file to make it possible to compile with cmake

Add icon from theme as an alternative while pixmap not set

Fixed

Then we don't need archive/lib

In D22644#500043, @vonreth wrote:

We usually place blueprints along with the blurepriints they are released with.
as this is currently unreleased maybe kde/unreleased?

I'll firstly do a quick fix

In D22558#499049, @vonreth wrote:

I think that change had some unforseen effects https://binary-factory.kde.org/job/Dolphin_Release_macos/498/console

In D22604#498997, @nicolasfella wrote:

KpeopleVcard is also needed to make the SMS app useful

In D22558#498087, @vonreth wrote:

Then they should be blacklisted. But if that's the right destination for those services they should all be moved.

In D22558#498042, @vonreth wrote:

Wouldn't the same not apply for others too?

Just copy the kioslave

In D22530#497350, @vonreth wrote:

Could you think ab out a more general solution? Maybe move it to the macdmgpackager?
In order to work this needs to be done for all packages, not only kde-connect.