Pure Qt kde-connect lib ?

[Albert Vaca]

On Wed, Mar 4, 2015 at 6:43 PM, Aleix Pol <aleixpol at kde.org> wrote:
> On Thu, Mar 5, 2015 at 1:34 AM, Lucien Xu <sfietkonstantin at free.fr> wrote:
>> ----- Mail original -----
>>> De: "Aleix Pol" <aleixpol at kde.org>
>>> À: "Lucien Xu" <sfietkonstantin at free.fr>
>>> Cc: kdeconnect at kde.org
>>> Envoyé: Mercredi 4 Mars 2015 23:43:03
>>> Objet: Re: Pure Qt kde-connect lib ?
>>>
>>> On Wed, Mar 4, 2015 at 10:50 PM, Lucien Xu <sfietkonstantin at free.fr>
>>> wrote:
>>> > Hello Alexis,
>>> >
>>> > (Sorry for top-posting, I'm using the webmail client)
>>> > Thanks for the quick answer. I will try to do some work in this
>>> > direction, cutting dependencies, in order to get some prototype
>>> > working on the Jolla. If I get something clean and working, I will
>>> > send it to the reviewboard.
>>> >
>>> > Regards,
>>> > Lucien
>>> >
>>> > ----- Mail original -----
>>> > De: "Aleix Pol" <aleixpol at kde.org>
>>> > À: "Lucien Xu" <sfietkonstantin at free.fr>
>>> > Cc: kdeconnect at kde.org
>>> > Envoyé: Mercredi 4 Mars 2015 22:26:58
>>> > Objet: Re: Pure Qt kde-connect lib ?
>>> >
>>> > On Wed, Mar 4, 2015 at 10:01 PM, Lucien Xu
>>> > <sfietkonstantin at free.fr> wrote:
>>> >> Hello list,
>>> >>
>>> >> Sorry if this question has already been answered, but has it been
>>> >> considered to write the KDE-connect core lib in pure Qt ? At the
>>> >> moment, the core lib in frameworks branch depends on KIO,
>>> >> KCMUtils, I18n, ConfigCore and Notifications. This requires these
>>> >> libs to be present on the platform where KDE-connect can be
>>> >> installed.
>>> >>
>>> >> Under normal circunstances (KDE SC 4, Plasma 2 under Linux for
>>> >> example), this should not be a problem. However, I'm trying to
>>> >> port KDE connect, both the desktop part (receiving information
>>> >> from phone), and the mobile part (sending information to the
>>> >> desktop), to some Qt-enabled platforms, like SailfishOS and
>>> >> Ubuntu touch. In these platforms, providing frameworks is less
>>> >> trivial, and having a pure Qt version might ease the porting
>>> >> task.
>>> >>
>>> >> In general, having a Qt version of the core lib (and plugins)
>>> >> could help targetting more platforms, and ease porting, however,
>>> >> I don't know if this can be done, or should be done.
>>> >>
>>> >> Any ideas ?
>>> >> Regards,
>>> >>
>>> >> Lucien
>>> >
>>> > Hi Lucien,
>>> > It's been thoroughly discussed, there's some kind of agreement that
>>> > this situation should be improved but we haven't found yet the
>>> > solution we want to go for.
>>> >
>>> > IMHO, a good first step could be to try to cut on the biggest
>>> > dependencies for the core part, such as KNotifications, Qt5Widgets
>>> > and
>>> > KIOWidgets. The other ones are quite small really and could be
>>> > easily
>>> > packaged into many platforms already.
>>> >
>>> > Once core and daemon (which is quite small itself) are runable,
>>> > then
>>> > we can consider to make it possible to easily disable some plugins
>>> > for
>>> > said platforms.
>>> >
>>> > Does that make sense to you?
>>> >
>>> > Cheers!
>>> > Aleix
>>>
>>> Hi Lucien,
>>> I just went through it and already could cut KIOWidgets (pending
>>> review), KCMUtils and KConfigWidets.
>>>
>>> With those out, the big remaining one will be KNotifications which is
>>> being used for the pairing. I'm thinking that maybe we can move this
>>> from standard notifications into a dbus API to be implemented by the
>>> different clients.
>>>
>>> What do you think, Albert?
>>>
>>> Aleix
>>>
>>> PS: I'm not Alexis ;)
>>>
>>
>> Hi Aleix,
>>
>> That's good news that cutting some dependencies are rather easy. However, I'm not a fan on depending heavily on KIO. Of course, it enables painless asynchronous job management, but it comes with some overhead. I was thinking of a generic interface that could be implemented by a KJob or by another way (like a QThread).
>>
>> At the moment, I did not do anything towards this, but am trying to libify the code, by enforcing Q_DECLARE_PRIVATE and Q_D and friends in the core lib. After that, I think that I will dig in this KNotifications thing. A DBus API could be nice as it could be handled by any kind of GUI.
>>
>> Regards,
>> Lucien
>>
>> PS: sorry, but I have a close friend called Alexis, and am used to type his name :D
>
> Hi,
> KIO worked on the N9/N900, I'm sure it can run properly on
> Jolla/UbuntuPhone. Please let's not discard things just like that. I'm
> all for cutting down, but let's not step on our toes.
>
> Instead of working on the library side, would you be interested in
> maybe getting a proof of concept of one of those client applications?
>
> Q_DECLARE_PRIVATE is nice, but kdeconnect is not public API yet, so
> it's not really needed.
>
> Aleix
>

Sorry for jumping on this thread late. I like the idea of a
multi-platform Qt client (probably with platform-specific plugins),
and even though I'm not working on that myself (mainly because not
many people talked about making KDE Connect work on other platforms)
I'm totally open for patches and improvements in that direction.
Actually, I think there is no other way to go if we want to support
multiple different platforms, as we can not afford having native code
for every single one.