[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-hardware-devel
Subject:    Re: [Kde-hardware-devel] [GSoC] Project: Make Libbluedevil Async
From:       Àlex Fiestas <afiestas () kde ! org>
Date:       2014-03-06 10:24:20
Message-ID: 6869483.uVOhLHqDYX () monsterbad
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 03 March 2014 23:35:14 David Rosca wrote:
> How exactly do you want to make the library async? I can see that there is
> a BlueDevil::asyncCall (for Device class) method for making async calls.
> Should the other classes be made asynchronous this way too (so both
> synchronous
> and asynchronous API is available)?
> Or change the API, that it will only be available asynchronous?
> 
> Thanks,
> David Rosca
> 
> [1] https://github.com/nowrep
> [2]
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/nowr
> ep/5681726336532480

Since libbluedevil is mostly a dbus wrapper of BlueZ I would use 
QDBusPendingReplyWatcher and wrap it with different jobs (or QFutures?), so the 
api would look something like this:

QBluezFetchDeviceInfo *jobInfo = Manager::self()->device("XX:xx:xx:xx:xx:x");
connect(jobIInfo, SIGNAL(finished()), SLOT(fetchInfoFinished());

jobInfo->start();

Note that I have used QBluez, I would like to rename it to that as well.

Also as part of the GSoC libbluedevil should be ported internally to this new 
async library, so I guess that jobs could have an aditional method making 
their execution sync, kinda:

jobInfo->exec();

That will use an internal QEventLoop to block execution until finished is 
emitted.

Also, we could do this using Qt5 so we can use lambdas and other nice stuff :)

Cheres!
["signature.asc" (application/pgp-signature)]

_______________________________________________
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel


[prev in list] [next in list] [prev in thread] [next in thread]