Single Qt codebase for kdeconnect

[Aleix Pol]

On Mon, Jan 19, 2015 at 10:37 PM, Pavel Borisov <pzinin at gmail.com> wrote:
> 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.
Maybe, in fact UI is the part that is less likely to be shared after all.

> So my proposal is like the folowing:
> 1) Rewrite interprocess communication using QLocalSocket (and QSharedMemory
> if needed) instead of D-Bus
This needs investigation. I have reports that dbus works properly on
OS X, Windows, Android and BBX.

> 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
Maybe.

> 3) Make universal client for everything (QtWidgets)
The only thing we have in QtWidgets now is the KCM. I would recommend
to get as a goal to have all UI in QML (at least the KDE part) so that
we make sure that the mobile clients will have the needed API.
Furthermore, Plasma integration (the plasmoid) is also QML/QtQuick.

> 4) Make Blackberry client (QML)
If anybody wants a Blackberry client that is.

> ...5) after related Android bug be fixed we can consider reusing UI from
> step 4 on Android.

Yes.

To be honest, I don't think it's that bigger of a change, it just
needs somebody who can start trying things.

Aleix