Ive got a bit to do, be prepared for a rev 2.

Biggest issue seems to be the notifications. It would be great to have a unified approach for that.

@vonreth Does Snorenotify support SailfishOS? And if not, would it be feasible to add? Using Snorenotify would also greatly improve our Windows experience.

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

Are you on irc at all?

In D10703#215044, @piggz wrote:

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

I don't know, unfortunately. Setting a breakpoint in PluginFactory.java:208 should help with debugging, though.

Are you on irc at all?

I didn't even know we had irc 😋

In D10703#215140, @mtijink wrote:

In D10703#215044, @piggz wrote:

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

I don't know, unfortunately. Setting a breakpoint in PluginFactory.java:208 should help with debugging, though.

Are you on irc at all?

I didn't even know we had irc 😋

Its not in the android app, its the C++/KDE project compiled for Sailfish, so im looking in pluginloader::pluginsForCapabilities

In D10703#215174, @piggz wrote:

In D10703#215140, @mtijink wrote:

In D10703#215044, @piggz wrote:

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

I don't know, unfortunately. Setting a breakpoint in PluginFactory.java:208 should help with debugging, though.

Are you on irc at all?

I didn't even know we had irc 😋

Its not in the android app, its the C++/KDE project compiled for Sailfish, so im looking in pluginloader::pluginsForCapabilities

After much debugging, i found the very simple, "IsEnabledByDefault" false !!!

@nicolasfella Thanks for pointing me to this. Happyness++

@piggz Hi :) By pure chance some hours before I came across https://github.com/R1tschY/harbour-sailfishconnect, is this some duplicated effort possibly or how does this relate? (no clue yet about KDE Connect details)

Can you give some build instructions? Seeing set(KF5_REQUIRED_COMPONENTS I18n DBusAddons CoreAddons), so not just using plain Qt, my old MarbleMaps@SailfishOS knowledge might not be sufficient :)

Happy to help out soon at least when it comes to MPRIS stuff (given master plan hinted to in D10972)

Guys, whats your thoughts about this?

Ive marked everything as 'done' so far, and quite happy to have removed the hack which compiled the declarative plugin into the app, and installed it properly. I should have done this from the start!

Also fixed the qAsConst issue by taking the code from qt 5.7. (btw, your min qt version is 5.2, which surely cant work?)

Perhaps the next change could be to abstract out the notifications code, so there was just one set of ifdef's for the different notification libs, but I dont want this to get too big a diff.

In D10703#217173, @kossebau wrote:

@nicolasfella Thanks for pointing me to this. Happyness++

@piggz Hi :) By pure chance some hours before I came across https://github.com/R1tschY/harbour-sailfishconnect, is this some duplicated effort possibly or how does this relate? (no clue yet about KDE Connect details)

Can you give some build instructions? Seeing set(KF5_REQUIRED_COMPONENTS I18n DBusAddons CoreAddons), so not just using plain Qt, my old MarbleMaps@SailfishOS knowledge might not be sufficient :)

Happy to help out soon at least when it comes to MPRIS stuff (given master plan hinted to in D10972)

@kossebau you can build by using the sfossdk and the supplied .spec file, so long as you have the deps from http://repo.merproject.org/obs/home:/piggz:/kf5/sailfishos_2.1.0.9_latest_armv7hl/ and https://build.merproject.org/project/show/nemo:devel:mw

How do you think this will work compared to a fully stanadalone client like the other you found?

In D10703#217493, @mtijink wrote:

I got some build errors, which I've added a comment for.

Nice to see KDE Connect spreading to a different platform. Do you have some screenshots?

If fix up the issues ... there is a screenshot of my desktop getting notifications here, https://twitter.com/adampigg/status/968600024316809218 ... i'll get some shots of the (currently very bare) client app later

In my theory it should work this way:

The daemon/ folder contains stuff for the desktop daemon, so it should not be included on sfos at all and should not need #ifdefs in the code.
The Sailfish daemon itself entirely lives within the sfos/ folder

I'm really concerned about how this is removing compilation of most plugins for sailfish. This means that this whole dance will be needed there once more for each plugin.

Has there been any talk to other Qt5-based projects which might be interested in sharing KDE Connect efforts? E.g. AsteroidOS might come into mind or Unity8, who both might be happy to be able to reuse at least the kdeconnect core lib, and then add their own UI to that.

What would you think about some kdeconnect-qtcore which get the content of "core/", ideally even without k18n (error messages could be done with UI-textless ids) and some hooks for config storage system.

In D10703#228012, @kossebau wrote:

Has there been any talk to other Qt5-based projects which might be interested in sharing KDE Connect efforts? E.g. AsteroidOS might come into mind or Unity8, who both might be happy to be able to reuse at least the kdeconnect core lib, and then add their own UI to that.

What would you think about some kdeconnect-qtcore which get the content of "core/", ideally even without k18n (error messages could be done with UI-textless ids) and some hooks for config storage system.

Someone had this idea sometime, but it didn't get much traction. Before we pursue this we should have close collaboration with at least one stakeholder, otherwise we might just waste our time. This could also be beneficial for alternative UIs like @andyholmes Gnome extension. Since he decided not to use the official KDE Connect core it would be nice to hear about his reasoning why he didn't so we know where we have to improve.

I think it could be a idea worth pursuing if we actually find people interested in it

I don't know much about Sailfish, but I heard that SailfishOS 3 with updated Qt is coming. Do you know how fast the rollout can be expected? It it better than Android where months after the release only 1% run the latest major? If version 3 is spreading reasonably fast we might require that and drop the Qt 5.6 hacks entirely

In D10703#228051, @nicolasfella wrote:

In D10703#228012, @kossebau wrote:

Has there been any talk to other Qt5-based projects which might be interested in sharing KDE Connect efforts? E.g. AsteroidOS might come into mind or Unity8, who both might be happy to be able to reuse at least the kdeconnect core lib, and then add their own UI to that.

What would you think about some kdeconnect-qtcore which get the content of "core/", ideally even without k18n (error messages could be done with UI-textless ids) and some hooks for config storage system.

Someone had this idea sometime, but it didn't get much traction.

Meanwhile found it (https://github.com/Bjoe/KConnectClientLib), next to @albertvaka 's take on it (https://albertvaka.wordpress.com/2014/10/23/kde-connect-feature-brainstorming/#comment-1599):

Actually I think this changes should be merged into the main git repo, so we don’t have to maintain two versions of the code. Right now the main repo is already split in more small parts, and for example the kded related code is already in a different directory. The last goal should be to have a Qt-only repo with a backend without user interface, and a different repo for the UI and KDE integration (plus another one for Gnome, Unity…), that should use DBus to communicate with the desktop-agnostic backend. This separation is quite done already, but not completely.

Which I understand as principle support for such a qtcore repo, at least at that time :)

Before we pursue this we should have close collaboration with at least one stakeholder, otherwise we might just waste our time.

Agreed.

This could also be beneficial for alternative UIs like @andyholmes Gnome extension. Since he decided not to use the official KDE Connect core it would be nice to hear about his reasoning why he didn't so we know where we have to improve.

I would assume the "improvement" needed would be to drop the usage of Qt libs, so possibly not to happen ;) BTW, actually I was surprised to see the KDE Connect Android not being done with Qt, but with native Java (or whatever the oficial language name is?). Similar motivation, I assume.

I think it could be a idea worth pursuing if we actually find people interested in it

If I look at this patch as well as the recent parallel effort https://github.com/R1tschY/harbour-sailfishconnect (who so created a fork for their needs) I would think some people are showing up now.Including myself, slowly getting my fingers dirty here :) Never managed to release something for Sailfish OS, only did some experiments with writing an app variant of Marble Maps for SailfishOS (as well as minimal rebuilding of Sailfish Office with Calligra code), so pretty interested to finally get something done and released, also for my usage needs. And with that experience, I also very much would prefer to have some non-QWidget-dependent code as common shared base.

For now though I would agree it is best to do the SFOS variant in the same repo. But then see to slowly prepare splitting things out. Not my call, just my 2 cents and showing up willing hands :) Time to get my SFOS SDK updated and working again, so I can do more than commenting. Even more as my latest commits made this patch no longer apply.

BTW, actually I was surprised to see the KDE Connect Android not being done with Qt, but with native Java (or whatever the oficial language name is?). Similar motivation, I assume.

I think this way it's easier to interact with the Android API which we rely on heavily.

Regarding the future of the SFOS port:
It would be great if we could get SnoreNotify on Sailfish. @kossebau would you consider trying to get a backend for that working?

Regarding the core lib thing: It would be great to get potentially interested people in a (virtual) room to talk about it

In D10703#228882, @nicolasfella wrote:

Regarding the future of the SFOS port:
It would be great if we could get SnoreNotify on Sailfish. @kossebau would you consider trying to get a backend for that working?

No promises, but note made. Never heard of that before.

Regarding the core lib thing: It would be great to get potentially interested people in a (virtual) room to talk about it

Note made as well :)

Starting to get it building, virtual sdk machine for now :)
Though had run into this:

CMake Error: File /home/src1/kdeconnect-kde/sfos/org.kde.kdeconnect.service.in does not exist.
CMake Error at sfos/CMakeLists.txt:24 (configure_file):
  configure_file Problem configuring file

Added locally a file sfos/org.kde.kdeconnect.service.in with this content:

[D-BUS Service]
Name=org.kde.kdeconnect
Exec=@DBUS_SERVICES_INSTALL_DIRR@/kdeconnectd

Still have to deploy to emulator, and then go for the real arch. Hoping that is without bigger hurdles as well, so I am soon ready to join development.

@piggz : I could not find this yet on merproject OBS, do you have a package spec/yaml file somewhere handy, so I can spare myself drafting one? :)

its not on obs yet. there is a spec in an earlier version of the diff, also take a look on my github maybe

In D10703#230820, @piggz wrote:

its not on obs yet. there is a spec in an earlier version of the diff, also take a look on my github maybe

Ah, missed that, thanks.

BTW, would you mind if I try to rebase this patch to latest master and then update the diff? Or are you already working on that?

Feel free, you'll have to implement the simple notification method in the Damon.