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).
Mon, Sep 16
Aug 19 2019
Aug 14 2019
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
Aug 4 2019
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
Aug 3 2019
Since objective-c stuff cannot co-work well with QML, the relevant solution is abandoned.
Is this good to ship?
Jul 30 2019
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
Jul 23 2019
Then we don't need archive/lib
Jul 22 2019
We usually place blueprints along with the blurepriints they are released with.
as this is currently unreleased maybe kde/unreleased?
Jul 21 2019
I'll firstly do a quick fix
I think that change had some unforseen effects https://binary-factory.kde.org/job/Dolphin_Release_macos/498/console
Jul 20 2019
Jul 19 2019
Then they should be blacklisted. But if that's the right destination for those services they should all be moved.
Just copy the kioslave
Jul 18 2019
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.
Jul 10 2019
Jul 9 2019
Jul 2 2019
Jun 30 2019
Jun 18 2019
Jun 9 2019
Jun 5 2019
Jun 4 2019
May 31 2019
May 28 2019
May 24 2019
May 19 2019
May 15 2019
May 10 2019
Mar 26 2019
I'm working for a native Windows notification APIs in this project.
Mar 7 2019
Glad to take this one.
Mar 5 2019
Hi everyone, I'm new here.
With a big interest of kdeconnect sms application and kdeconnect itself, I'd like to take some efforts in this task. And in the future the others :)