Collaboration in kdeconnect-kde repo?

[kossebau]

Hi @R1tschY,
happy to have found your work on giving us SFOS users finally native access to the world of kdeconnect. Though at the very same time I also discovered a parallel effort, by a patch for kdeconnect-kde repo itself, https://phabricator.kde.org/D10703 (with work & updates prepared here: https://github.com/piggz/kdeconnect-kde/tree/pgz-sfos-initial)

Myself being also a contributor to KDE projects, including kdeconnect since very recently, and knowing the people, I jumped on the other patch for now :) Also because working on the original code allows more influence on things possibly needed for SFOS.

Then of course it would be great to have people join efforts where possible. When it comes to SFOS, of course all the extra deps currently pulled in for the Plasma-oriented codebase of kdeconnect-kde ideally would be avoidable. @piggz' work here has started that, for now by removing the dependency on KNotifications. And for the future there might be the option of a pure-qt-based kdeconnect core, see e.g. things noted in the comment https://phabricator.kde.org/D10703#228863

So I would like to invite you to consider joining the kdeconnect project, and work together with piggz, me and others to have SFOS a first-class platform directly supported by the original project. Do not hesitate to ask me for more information here, happy to reply to any questions.

Cheers
Friedrich

[R1tschY]

Hi Friedrich,

as I started developing this app, I didn't know about the efforts being do in the KDE Connect project. I just wanted to build a running app supporting KDE Connect. So I copied the code and removed all dependencies to KDE libs.

Thank you for letting me know that there is a app that maybe does better than mine. I don't know, but it seems that the app from @piggz does already more than mine. So I will discontinue this project.

I don't see any chance to merge both projects. It uses code from the same core lib, but in harbour-sailfishconnect all KDE deps are replaced. I don't think the KDE Connect project would allow anyone to replace them in particular the plugin interface. If the will is there, I can merge same parts of the UI and a bug fix (8634d6e).

1. Are there any parts of harbour-sailfishconnect that are useful in kdeconnect-kde?
2. How is the work coordinated/planned?
3. What needs to be done in the kdeconnect-kde SailfishOS port? What can I do?
4. Is there any concept for SailfishOS-only plugins like a Telephony-Plugin through ofono?

I can give no guaranty of how much time I will have to work on the kdeconnect-kde project.

[piggz]

Hi both

I havnt tried your app yet, but it could easily be better than mine atm! I have just done some basic porting to build the kde version on sailfish, plus a simple gui based on the kde experimental app.

The daemon seems a bit crashy, i keep getting disconnects, so that needs looked into.
To answer your questions

1. Anything you can suggest?
2. Work on kde apps and kdeconnect is via phabricator....clone, mod, submit a diff for review, rework from comments, then land in the main repo
3. Do anything you like, fix bugs, add features
4. Certainly I think, like you suggest, an ofono telephone plugin would be a start. Ive not used the android app, so there is bound to be things that need a sfos port there.

[R1tschY]

I looked more into the code and I found multiple problems:

1. the app is not prefixed with harhour- so it cannot be uploaded to the harhour-store
2. the plugins of the desktop client cannot be reused except the clipboard plugin
   • we use nemonotifications
   • we have to share the battery state instead of showing the battery state of the other device. harbour-sailfishconnect uses the statefs-api for getting the battery state
   • most of the plugins will get SailfishOS specific code, I think and I hate ifdef's
3. we have to statically link to the KF5 libs to get one rpm and pass the checks so we can upload it to harbour
4. maybe use qmake to get a better integration/deployment/debugging with QtCreator/SailfishOS-IDE

I would suggest to use a new repo and use kdeconnect-kde through a gitmodule. In the future a migration to kdeconnect-core/libkdeconnect would be possible. Which is than freed from its KF5 deps.

In harbour-sailfishconnect I already implemented:

• a battey-plugin which shares the battery state
• a ui for pairing and plugin enabling

I will try to build @piggz' work to get a better overview. But until it is more clear how the problems are solved, I will continue developing on this project. Later the things can be merged. I will try using the dbus-damon approach of @piggz so that merging in the future will be easier.

[piggz]

Hi

youre right on all points...

1/3/4, my plan is to reduce maintenace by using upstream as much as possible, this will likely mean I cant put it in the jolla store, but openrepos and obs will be fine. I envisage using kf5 libs as regular packages on an openrepos account to solve the dependencies.

2. The sendnotification and remote control plugins also work, the sendnotification plugin being the main use case for me at the moment.

I hope there is areas to collaborate on

[R1tschY]

Okay, my aim is to publish in the harbour store. So we need two different repos/apps.

I could share bugfixes and plugin implementations.

[kossebau]

Thanks for the replies @R1tschY & @piggz , glad to see the discussion :)

I had stayed silent so far being the newbie here (though getting my fingers already dirty with patches for new plugins "New plugin: Find this device" and "Add plugins for controlling remote & exposing local screen brightness" for kdeconnect-kde).
Now with my brain slowly wrapping around the base code, I see that the initial naive hope "oh, Qt everywhere, so just needs a recompile" again does not apply, and not just for the UI/presentation layer (where expected & personally also prefer native UI).
As you already said, given that kdeconnect-kde does not simply rely on Qt abstraction layers, but uses KF5 extensions even in the core library as well as direct platform-dependent implementations in many of the plugins for wiring up to the platform for whatever the plugins do, building the kdeconnect-kde code directly on the SFOS platform will need a lot of ifdefs, which open the door to development hell (especially as there is no SFOS platform support currently on KDE CI, and no-one known to have time to invest into that, so regressions for other platforms will be hard to catch for non-platform developers, resulting in frustration). So the costs of maintaining implementation variants in the same codebase might eat any advantages of code reuse, Even for the kdeconnectcore.

Then I also would prefer having whatever kdeconnect-sfos in the Jolla store, given this allows more outreach of this nice functionality.

So with my current understanding of the matters, I would think that continuing harbour-sailfishconnect indeed makes sense. And thus I will see to work on adding/porting some plugins for it in the future. Of course happily sharing any plugin work also to @piggz version, being mainly interested to have whatever approach will succeed long-term to be as feature-rich as possible :)

Having another separate implementation might also increase motivation to start some proper (formal) documentation for the individual plugin commands, where currently it is just "the code" which tells what command with which parameters are known for which packet types.

I still hope at least kdeconnectcore can be turned by the time into a Qt-modules-only library, so it can be reused by any Qt-based system. Given that the used KF5 extensions can be substituted with Qt-only code as seen here. For that goal then I also hope/suggest that the forked core lib is kept as close as possible APIwise for now.

[R1tschY]

You are welcome to add plugins or features.

I feel bad about the quick port of the core lib. But on the other hand I have a good integration. The API will stay compatible to the original core lib. A pure-Qt core lib would be great. But the KF5 deps could also be deployed in a app own lib folder: /usr/share/<appname>/lib. ATM I will use my quick port.

I will do my best to make the best sfos kdeconnect app :)

[nicolasfella]

Hey, late to the party but here are my two cents as upstream KDE Connect developer (that has never none anything wrt Sailfish)

1. the app is not prefixed with `harhour-` so it cannot be uploaded to the harhour-store

That's a WTF to me, but I guess nothing you and I can do about

2. the plugins of the desktop client cannot be reused except the clipboard plugin

I'm pretty sure there are more plugins that are/could be made useful

   * we use nemonotifications

That should be solvable by adding a nemonotifications plugin to KNotifications (we recently added one for Android)

   * we have to share the battery state instead of showing the battery state of the other device. harbour-sailfishconnect uses the statefs-api for getting the battery state

It shouldn't be hard to make a SFOS battery plugin for that

   * most of the plugins will get SailfishOS specific code, I think and I hate ifdef's

Instead of ifdefing in the plugin code one could have different, independent plugins that are selected at build time

3. we have to statically link to the KF5 libs to get one rpm and pass the checks so we can upload it to harbour

Statically linking KF5 is possible (https://volkerkrause.eu/2018/10/13/kf5-static-builds.html) and we can address any remaining blockers for that

4. maybe use qmake to get a better integration/deployment/debugging with QtCreator/SailfishOS-IDE

We're not going to port to qmake. Even Qt is porting from qmake to CMake for Qt6

I would suggest to use a new repo and use kdeconnect-kde through a gitmodule. In the future a migration to kdeconnect-core/libkdeconnect would be possible. Which is than freed from its KF5 deps.
I don't see the point in getting rid of KF5 dependencies. The core only has a few: KI18n, KCoreAddons, KConfig (which are all Tier 1, meaning they have no other dependencies), QCA (which we are porting away from https://phabricator.kde.org/D17790) and KIO (which isn't particularly nice since it has quite a lot of dependencies itself). We could port the core away from KIO by making it build-time optional. That would reduce the amount of deps significantly.

We are developing a Kirigami-based UI for Plasma Mobile. Ideally we'd use that on SFOS as well, but since Kirigami depends on Qt 5.10 this probably cannot be done. For Plasma mobile we will also work on Ofono-based SMS and Telephony plugins which will be useful for SFOS as well I assume.

TL;DR
I'd like to see closer collaboration since we both target a Qt-based mobile OS (SFOS and Plasma Mobile)
I don't share the view that KF5 deps are bad, however I agree that getting rid of KIO for the core would be nice (and possible)
We could share the core and plugins that do not require SFOS specific code

[R1tschY]

I through about your ideas. Bringing both projects more together will be a longer process. Both sides have to remove some obstacles.

From my side I started experimenting using Conan for dependency building. I'm not a fan of QMake, but the CMake integration in the Sailfish SDK QtCreator is bad, so the app will be build with QMake and all dependencies with CMake (instead of git submodules). I hope it works. Using the Tier 1 KF5 deps should be no problem.

KIO is to big and not used that much in the core (lib: KIO::AccessManager, share-plugin: KIO::getJobTracker, KIO::suggestName, KIO::mkpath). Ifdefing the KIO::AccessManager should be enough. For the QCA dep you can take a look at my working implementation: https://github.com/R1tschY/harbour-sailfishconnect/blob/master/lib/sailfishconnect/helper/sslhelper.cpp

Instead of ifdefing in the plugin code one could have different, independent plugins that are selected at build time

Right. Should be easily done in cmake.

We are developing a Kirigami-based UI for Plasma Mobile. Ideally we'd use that on SFOS as well, but since Kirigami depends on Qt 5.10 this probably cannot be done. For Plasma mobile we will also work on Ofono-based SMS and Telephony plugins which will be useful for SFOS as well I assume.

In near future I don't see any possibility for a Kirigami-based SFOS app. A Ofono-based plugin (Telephony) already exist in SailfishConnect.

At first I will try to build SailfishConnect with KF5 dependencies. Then I will try to migrate to kdeconnect core lib creating some merge requests with the things that I modified in SailfishConnect. I don't know how long it will take.

[piggz]

fantastic, i would love to see your contributions merged with mine in the main kdeconnect repo. There are several examples in the repo cmakelists files where plugins are optionally compiled for sailfish or other platforms, so adding your ofono plugin should be a breeze.

I agree kirigami will probably be a while, i think it needs qt5.10,and we will only be getting 5.9 next.

The current sailfish build in kdeconnect already gets rid of kio, replacing it with qnam, so that too shouldnt be a blocker.

[nicolasfella]

I'm willing to work on removing those obstacles on our side.
We are having a KDE Connect sprint in Nürnberg, Germany from 19.7.-21.7. That would be a great opportunity to work on this. Any chance you could come? See https://community.kde.org/Sprints/KDE_Connect/2019 for more information

[R1tschY]

Sounds good. I'm considering to come to Nürnberg.

[R1tschY]

I will close this, because KDE Connect and Sailfish Connect are collaborating since Nürnberg.