D10703: Build kdeconnect on sailfish and port some simple plugins

Sun Mar 18 23:22:27 UTC 2018

kossebau added a comment.

  In D10703#228051 <https://phabricator.kde.org/D10703#228051>, @nicolasfella wrote:

  > In D10703#228012 <https://phabricator.kde.org/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 <https://frinring.wordpress.com/2015/11/25/marble-maps-forking-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.

REPOSITORY
  R224 KDE Connect

REVISION DETAIL
  https://phabricator.kde.org/D10703

To: piggz, #kde_connect, apol, mtijink
Cc: andyholmes, albertvaka, kossebau, mtijink, vonreth, apol, #kde_connect, nicolasfella, adeen-s, SemperPeritus, ahmedbesbes, daniel.z.tg, jeanv, seebauer, bugzy, MayeulC, menasshock, ach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20180318/cad06df5/attachment-0003.html>