Single Qt codebase for kdeconnect

[Pavel Borisov]

On 19.01.2015 18:35, Aleix Pol wrote:
> On Sun, Jan 18, 2015 at 11:50 PM, Pavel Borisov <pzinin at gmail.com> wrote:
>> Hello.
>> It looks unlikely from here that it is possible to distinguish a single
>> codebase for all sorts of platforms.
>>
>> The highest support that we have from Qt library is undoubtedly Blackberry.
>> Although, Qt has Native Style for Android since 5.4 so presumably no problem
>> here from user's point of view.
>>
>> The main problem of all the time is: Qt does not have a single unified
>> interface for services. On the other hand, kdeconnect must be in background
>> in order to receive incoming connections. So what we have now:
>> - Blackberry: complete Qt-based framework for services: the concept of
>> Headless Application:
>> http://developer.blackberry.com/native/documentation/cascades/device_platform/headless_apps/
>> - Android: not implemented yet: https://bugreports.qt.io/browse/QTBUG-37221
>> - Windows RT: nothing
>>
>> But even by the time related bug is fixed, we will have been encountering a
>> major problem: unification between Blackberry and Android service framework
>> (+ Windows).
>> It might end up with writing a middleware for service to be working. Pretty
>> much all I can say for now - not with current Qt release. It is due to not
>> only  my previous statements but also owing to this Windows-related issue:
>> https://bugreports.qt.io/browse/QTBUG-40922
>>
>> It might be more realistic to develop a separate client - at least for now -
>> for every platform. However it could be possible to have the same client for
>> everything without background service. A huge drawback.
> On the other hand, maybe it would make sense to spend some time into
> sorting these out. Android is the platform I'm less worried about,
> many people are using it already, I'm more concerned about other
> platforms that are a bit more of a niche.
>
> Also the fact that we might want to target the different platforms
> specifically doesn't mean they can't share any code whatsoever. If we
> agree that it's not acceptable to have a daemon for every platform, we
> can just share code through libkdeconnect. In fact, it just started
> being a daemon rather recently, it used to be a kded plugin until not
> that long ago.
>
> Aleix
Yes. You are absolutely right.
KDEConnect should be divided into three parts: UI, Daemon and libkdeconnect.
So my proposal is like the folowing:
1) Rewrite interprocess communication using QLocalSocket (and 
QSharedMemory if needed) instead of D-Bus
2) Move everything in core in separate shared library "libkdeconnect"
On KDE the stuff should work as it was before (we can still use kded). 
On the other hand, codebase will be ready to target Blackberry, and 
desktop systems other than KDE. On Blackberry we can use their native 
API (see link above). On Gnome, OSX etc we can just use QtService class 
(https://github.com/qtproject/qt-solutions/tree/master/qtservice) which 
has been updated for qt5 recently. So
3) Make universal client for everything (QtWidgets)
4) Make Blackberry client (QML)
...5) after related Android bug be fixed we can consider reusing UI from 
step 4 on Android.

-- 
Best regards, Pavel Borisov
Jabber ID: pashazz at gentoo.ru