Pure Qt kde-connect lib ?

[Lucien Xu]

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