Re: Falkon in kdereview
On Sun, Mar 25, 2018 at 11:08 PM, David Rosca <now...@gmail.com> wrote: > On Sat, Mar 24, 2018 at 7:58 PM, Dr.-Ing. Christoph Cullmann > <cullm...@absint.com> wrote: >> Hi, >> >> no objections from my side, >> >> just a note that we need to take care of the last remaining things on >> >> https://community.kde.org/Incubator/Projects/Falkon >> >> for the final incubation to be done. >> >> I think the mailing list/website stuff shouldn't be an issue to get done. > > I've requested mailing list creation, but I'm not sure about the > website. Does it have to be a site under kde.org (subdomain)? If yes, > then I'm afraid I have no idea how to proceed there. The other option > is to host it on my server, as is www.qupzilla.com right now. > For the site contents it would be enough just basic info and download > links, I think. > Mailing list and websites are now up and running. Repository was also moved to extragear. Incubation should be completed now. David >> >> The Manifest compliance is IMHO there, licensing stuff was reviewed some >> weeks >> ago if I am not mistaken. > > Manifest compliance is done I hope. Licensing should be ok now too. > > David > >> >> Greetings >> Christoph >> >> - Am 20. Mrz 2018 um 13:40 schrieb nowrep now...@gmail.com: >> >>> On Wed, Feb 28, 2018 at 12:10 PM, David Rosca <now...@gmail.com> wrote: >>>> Hi, >>>> I'd like to request review for Falkon. >>>> >>> >>> All issues that were pointed out are now fixed. >>> >>> It's been in kdereview for over two weeks now, so if there are no >>> objections I will request move to extragear by the end of this week. >>> >>> David >> >> -- >> - Dr.-Ing. Christoph Cullmann - >> AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com >> Science Park 1 Tel: +49-681-38360-22 >> 66123 Saarbrücken Fax: +49-681-38360-20 >> GERMANYWWW: http://www.AbsInt.com >> >> Geschäftsführung: Dr.-Ing. Christian Ferdinand >> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Falkon in kdereview
On Sat, Mar 24, 2018 at 7:58 PM, Dr.-Ing. Christoph Cullmann <cullm...@absint.com> wrote: > Hi, > > no objections from my side, > > just a note that we need to take care of the last remaining things on > > https://community.kde.org/Incubator/Projects/Falkon > > for the final incubation to be done. > > I think the mailing list/website stuff shouldn't be an issue to get done. I've requested mailing list creation, but I'm not sure about the website. Does it have to be a site under kde.org (subdomain)? If yes, then I'm afraid I have no idea how to proceed there. The other option is to host it on my server, as is www.qupzilla.com right now. For the site contents it would be enough just basic info and download links, I think. > > The Manifest compliance is IMHO there, licensing stuff was reviewed some weeks > ago if I am not mistaken. Manifest compliance is done I hope. Licensing should be ok now too. David > > Greetings > Christoph > > - Am 20. Mrz 2018 um 13:40 schrieb nowrep now...@gmail.com: > >> On Wed, Feb 28, 2018 at 12:10 PM, David Rosca <now...@gmail.com> wrote: >>> Hi, >>> I'd like to request review for Falkon. >>> >> >> All issues that were pointed out are now fixed. >> >> It's been in kdereview for over two weeks now, so if there are no >> objections I will request move to extragear by the end of this week. >> >> David > > -- > - Dr.-Ing. Christoph Cullmann - > AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com > Science Park 1 Tel: +49-681-38360-22 > 66123 Saarbrücken Fax: +49-681-38360-20 > GERMANYWWW: http://www.AbsInt.com > > Geschäftsführung: Dr.-Ing. Christian Ferdinand > Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Falkon in kdereview
On Wed, Feb 28, 2018 at 12:10 PM, David Rosca <now...@gmail.com> wrote: > Hi, > I'd like to request review for Falkon. > All issues that were pointed out are now fixed. It's been in kdereview for over two weeks now, so if there are no objections I will request move to extragear by the end of this week. David
Re: Falkon in kdereview
On Sat, Mar 3, 2018 at 6:47 PM, Albert Astals Cid <aa...@kde.org> wrote: > El dimecres, 28 de febrer de 2018, a les 12:10:36 CET, David Rosca va > escriure: >> Hi, >> I'd like to request review for Falkon. >> >> It's been actually in kdereview for some time already, but I never got >> to properly request review, sorry about that. >> >> There is a project set up in bugzilla, CI build and code should be in >> accordance with guidelines too. >> There are also some autotests, although they are rather unstable on >> FreeBSD build. It looks like crash in QtWebEngine, but the backtrace >> from CI is without symbols, so it is unfortunately useless. >> >> Target is Extragear for now, and later possibly moving to KDE Applications. > > Looks really nice :) > > One small fix you need to do, you need to also exclude scripts from your src/ > Messages.sh Right, I missed that, thanks. > > the look of your scripts/Messages.sh file looks like it's trying to be too > smart and it'll confuse some of our tools that may try to guess which .po > files need packaging, i'd really suggest having one Messages.sh per subfolder, > since after all you still need to edit the python_scripts variable so it's not > automagic that any added script will get the .po extracted. I did it this way so that the entire folder with python extension can be installed with simple install(DIRECTORY ...) without excluding anything. It seemed to work fine, but I'll change it so there is Messages.sh in each subfolder. > > also two random comments, probably you can ignore most of them but since i > spent some time i'll just comment. > * I think you need a qDeleteAll in AdBlockSubscription::loadSubscription > before m_rules.clear(); Yes > * The bookmarks text in https://i.imgur.com/xkELczj.png doesn't fit here It probably needs to remove titles completely, as they may be very long depending on translation, and width of that sidebar should be fixed. David > > Cheers, > Albert > >> >> Thanks, >> David > > > >
Falkon in kdereview
Hi, I'd like to request review for Falkon. It's been actually in kdereview for some time already, but I never got to properly request review, sorry about that. There is a project set up in bugzilla, CI build and code should be in accordance with guidelines too. There are also some autotests, although they are rather unstable on FreeBSD build. It looks like crash in QtWebEngine, but the backtrace from CI is without symbols, so it is unfortunately useless. Target is Extragear for now, and later possibly moving to KDE Applications. Thanks, David
Moving libbluedevil to unmaintained
Hi all, with Bluedevil now ported to BluezQt and with regard to no more kdelibs4 Bluedevil releases, I will no longer work on libbluedevil. Porting from libbluedevil to BluezQt is pretty straightforward (only problem might be async initialization), so I suggest to anyone still using libbluedevil to switch to BluezQt. If there are no objections in next 2 weeks, I will ask to move libbluedevil to unmaintained. David
Re: Review request: QBluez
Do you expect the bluez-qt branch of bluedevil to be ready to merge before Plasma 5.3 freeze on Thu 9 April? Currently, this branch is old and still using old name qbluez. I will update it and work on it in next days to make it ready for Plasma 5.3. David On Thu, Mar 12, 2015 at 8:26 PM, Jonathan Riddell j...@jriddell.org wrote: On Thu, Mar 12, 2015 at 08:23:22PM +0100, David Rosca wrote: Done. It's in kdereview now: https://projects.kde.org/projects/kdereview/bluez-qt Woo, lovely. Best post to plasma-devel about that (it's been posted around lots already but best to cover all the bases I guess.) Do you expect the bluez-qt branch of bluedevil to be ready to merge before Plasma 5.3 freeze on Thu 9 April? Jonathan
Re: [kde-frameworks-devel] Review request: QBluez
On Wed, Mar 11, 2015 at 6:49 PM, Jonathan Riddell j...@jriddell.org wrote: The name KF5BluezQt seems inelegant, is has both a prefix and a suffix, how about just KF5Bluez? That would work, but only for cmake files, otherwise I would have to change namespace from BluezQt to just Bluez, which is obviously not a right thing. The headers get installed into /usr/include/BluezQt/, I guess that should be /usr/include/KF5/BluezQt/ ? It requires extra-cmake-modules 1.8 but seems to compile fine with 1.7. Fixed Do you expect this to be moved into KDE Frameworks? That gets tagged on April 4th. Or do you expect it to be moved into kde/workspace for release with Plasma? That gets tagged in April 9th. If it goes into Frameworks it must remain API and ABI compatible while in Plasma you only need to bump the soversion if it changes. Is it ready for that? Originally, I wanted to move it to frameworks. But if i think about it again, I plan to extend the library with new features which may break the ABI. So, I would like to move it to kde/workspace once reviewed. Thanks, David
Re: Review request: QBluez
I have made yet another changes and I think it is ready to be used in Bluedevil. However, I'm not really sure how should I proceed now. Can I move it to playground repo (+ add it to reviewboard and set a jenkins build)? Would it be ok for a Bluedevil (in workspace) to depend on a library in playground? After that, I'd like to request a review to make BluezQt an official framework. Or should I get it reviewed first and use it in Bluedevil only after reviewed? Thanks, David On Sat, Feb 21, 2015 at 1:36 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 21 de febrer de 2015, a les 00:24:16, David Rosca va escriure: Still failing here Oops, sorry. It's because the problem is not that you are running Bluez 4, but because the method call is rejected (auth issue?). Anyway, I modified the tests again so that it now checks whether the Bluez 5 is running and is functional (it checks if the call to GetManagedObjects succeeds). It should catch your error and correctly skip the tests now. Yep that's all fine now :) Cheers, Albert David On Fri, Feb 20, 2015 at 9:57 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 18 de febrer de 2015, a les 11:50:01, David Rosca va escriure: If it's an expected situation, handle the situation. I have modified the tests (only the ones who would fail) so they will be skipped if Bluez 4 is detected. Still failing here 4: Test command: /home/kdeunstable/qbluez/build/autotests/adaptertest 4: Test timeout computed to be: 9.99988e+06 4: * Start testing of AdapterTest * 4: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 4: QWARN : AdapterTest::initTestCase() BluezQt: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.145 (uid=1003 pid=10596 comm=/home/kdeunstable/qbluez/build/autotests/adapterte) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=556 comm=/usr/sbin/bluetoothd ) 4: FAIL! : AdapterTest::initTestCase() '!initJob-error()' returned FALSE. () 4: Loc: [/home/kdeunstable/qbluez/autotests/adaptertest.cpp(76)] 4: PASS : AdapterTest::cleanupTestCase() 4: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 4: * Finished testing of AdapterTest * 4/6 Test #4: bluezqt-adaptertest ..***Failed0.01 sec test 5 Start 5: bluezqt-devicetest 5: Test command: /home/kdeunstable/qbluez/build/autotests/devicetest 5: Test timeout computed to be: 9.99988e+06 5: * Start testing of DeviceTest * 5: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 5: QWARN : DeviceTest::initTestCase() BluezQt: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.146 (uid=1003 pid=10597 comm=/home/kdeunstable/qbluez/build/autotests/devicetes) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=556 comm=/usr/sbin/bluetoothd ) 5: FAIL! : DeviceTest::initTestCase() '!initJob-error()' returned FALSE. () 5: Loc: [/home/kdeunstable/qbluez/autotests/devicetest.cpp(96)] 5: PASS : DeviceTest::cleanupTestCase() 5: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 5: * Finished testing of DeviceTest * 5/6 Test #5: bluezqt-devicetest ...***Failed0.01 sec I have also renamed the library to BluezQt. Here is an updated documentation: http://david.rosca.cz/bluezqt-apidocs/html/ David On Wed, Feb 18, 2015 at 2:19 AM, Thiago Macieira thi...@kde.org wrote: On Tuesday 17 February 2015 23:00:15 Albert Astals Cid wrote: It doesn't have the DBus ObjectManager, so that call should fail like that. Well, then the test should try to detect it and QEXPECT_FAIL, havign tests fail means something is bad, and as you say it's not bad, just expected. QEXPECT_FAIL is when you know it's wrong but either can't solve it or can't do it now. If it's an expected situation, handle the situation. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review request: QBluez
Still failing here Oops, sorry. It's because the problem is not that you are running Bluez 4, but because the method call is rejected (auth issue?). Anyway, I modified the tests again so that it now checks whether the Bluez 5 is running and is functional (it checks if the call to GetManagedObjects succeeds). It should catch your error and correctly skip the tests now. David On Fri, Feb 20, 2015 at 9:57 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 18 de febrer de 2015, a les 11:50:01, David Rosca va escriure: If it's an expected situation, handle the situation. I have modified the tests (only the ones who would fail) so they will be skipped if Bluez 4 is detected. Still failing here 4: Test command: /home/kdeunstable/qbluez/build/autotests/adaptertest 4: Test timeout computed to be: 9.99988e+06 4: * Start testing of AdapterTest * 4: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 4: QWARN : AdapterTest::initTestCase() BluezQt: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.145 (uid=1003 pid=10596 comm=/home/kdeunstable/qbluez/build/autotests/adapterte) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=556 comm=/usr/sbin/bluetoothd ) 4: FAIL! : AdapterTest::initTestCase() '!initJob-error()' returned FALSE. () 4:Loc: [/home/kdeunstable/qbluez/autotests/adaptertest.cpp(76)] 4: PASS : AdapterTest::cleanupTestCase() 4: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 4: * Finished testing of AdapterTest * 4/6 Test #4: bluezqt-adaptertest ..***Failed0.01 sec test 5 Start 5: bluezqt-devicetest 5: Test command: /home/kdeunstable/qbluez/build/autotests/devicetest 5: Test timeout computed to be: 9.99988e+06 5: * Start testing of DeviceTest * 5: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 5: QWARN : DeviceTest::initTestCase() BluezQt: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.146 (uid=1003 pid=10597 comm=/home/kdeunstable/qbluez/build/autotests/devicetes) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=556 comm=/usr/sbin/bluetoothd ) 5: FAIL! : DeviceTest::initTestCase() '!initJob-error()' returned FALSE. () 5:Loc: [/home/kdeunstable/qbluez/autotests/devicetest.cpp(96)] 5: PASS : DeviceTest::cleanupTestCase() 5: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 5: * Finished testing of DeviceTest * 5/6 Test #5: bluezqt-devicetest ...***Failed0.01 sec I have also renamed the library to BluezQt. Here is an updated documentation: http://david.rosca.cz/bluezqt-apidocs/html/ David On Wed, Feb 18, 2015 at 2:19 AM, Thiago Macieira thi...@kde.org wrote: On Tuesday 17 February 2015 23:00:15 Albert Astals Cid wrote: It doesn't have the DBus ObjectManager, so that call should fail like that. Well, then the test should try to detect it and QEXPECT_FAIL, havign tests fail means something is bad, and as you say it's not bad, just expected. QEXPECT_FAIL is when you know it's wrong but either can't solve it or can't do it now. If it's an expected situation, handle the situation. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review request: QBluez
Using Q* is usually frowned upon since the Qt people have made it quick clear that they reserve the right to use Q* names themselves, i'd look for a new name. I see. What about renaming it to BluezQt? Also tried to run the tests and qbluez-managertest seems to get stuck forever. Does it take much to run? Does it need that i actually have bluetooth hardware? Tests are running with both real org.bluez (system bus) and fake org.qbluez.bluez (session bus). You don't need to have any bluetooth hardware, nor Bluez installed at all to run the tests. The reason why it hangs is probably that fakebluez cannot, for some reason, start. I have pushed a change that fixes the hang, and also show some info why it cannot start. Can you please send me the output of qbluez-managertest? Thanks, David On Mon, Feb 16, 2015 at 11:51 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 16 de febrer de 2015, a les 10:40:44, David Rosca va escriure: Hi all, I'd like to ask for a review of the QBluez library [1]. Using Q* is usually frowned upon since the Qt people have made it quick clear that they reserve the right to use Q* names themselves, i'd look for a new name. Also tried to run the tests and qbluez-managertest seems to get stuck forever. Does it take much to run? Does it need that i actually have bluetooth hardware? Cheers, Albert QBluez is a Qt 5 wrapper for Bluez 5 DBus API. I have started working on it as a GSoC 2014 project. It is intended to be a libbluedevil replacement, main difference being that every DBus call is made asynchronous. It also exposes more Bluez API than libbluedevil, including Obex API. This library will be used in Bluedevil frameworks branch. I have also written a new Bluetooth plasmoid [2] that uses a QBluez QML plugin. Bellow is a list of some additional QBluez features compared to libbluedevil: * it is a tier 1 framework * asynchronous API using jobs/pending calls with possibility to run synchronously (for tests/cli apps) * extended API - this currently includes API for Obex File Transfer, Obex Object Push and Profile API for implementing Bluetooth profiles * build-time optional QML plugin - currently exposing Manager, Adapter, Device, DevicesModel and PendingCall * possibility to be notified when method call finishes and to be notified about possible errors Currently, there is a qbluez branch in Bluedevil [3]. It will be merged to frameworks branch once QBluez is reviewed. You can find generated documentation here [4]. Thanks, David Rosca [1] http://quickgit.kde.org/?p=scratch%2Fdrosca%2Fqbluez.git [2] https://github.com/nowrep/qbluez-plasmoid [3] https://projects.kde.org/projects/kde/workspace/bluedevil/repository/show?r ev=qbluez [4] http://david.rosca.cz/qbluez-apidoc/html/ ___ Kde-frameworks-devel mailing list kde-frameworks-de...@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review request: QBluez
Well, then the test should try to detect it and QEXPECT_FAIL, havign tests fail means something is bad, and as you say it's not bad, just expected. I meant it's expected to fail in the case that something goes wrong when initializing Manager. And that is, for example, the case with running Bluez 4 instead of Bluez 5. The problem is that there are some tests that are running on the real Bluez daemon and those tests obviously requires Bluez 5. They won't fail when there is no org.bluez on system bus, but they will actually fail when there is org.bluez but provided by Bluez 4. I will modify those tests to be skipped if Bluez 4 is detected. David On Tue, Feb 17, 2015 at 11:00 PM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 17 de febrer de 2015, a les 22:39:16, David Rosca va escriure: That would work i guess, note it's not only about the project name, but also about the class names. Sure. But i get two others to fail Any idea? Hmm, I would say that it is actually expected to fail if there is an error when calling GetManagedObjects on org.freedesktop.DBus.ObjectManager. By any chance, are you running Bluez 4? I am. It doesn't have the DBus ObjectManager, so that call should fail like that. Well, then the test should try to detect it and QEXPECT_FAIL, havign tests fail means something is bad, and as you say it's not bad, just expected. Cheers, Albert David On Tue, Feb 17, 2015 at 10:23 PM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 17 de febrer de 2015, a les 10:36:59, David Rosca va escriure: Using Q* is usually frowned upon since the Qt people have made it quick clear that they reserve the right to use Q* names themselves, i'd look for a new name. I see. What about renaming it to BluezQt? That would work i guess, note it's not only about the project name, but also about the class names. Also tried to run the tests and qbluez-managertest seems to get stuck forever. Does it take much to run? Does it need that i actually have bluetooth hardware? Tests are running with both real org.bluez (system bus) and fake org.qbluez.bluez (session bus). You don't need to have any bluetooth hardware, nor Bluez installed at all to run the tests. The reason why it hangs is probably that fakebluez cannot, for some reason, start. I have pushed a change that fixes the hang, and also show some info why it cannot start. Can you please send me the output of qbluez-managertest? Now it doesnt' fail :D But i get two others to fail 4: Test command: /home/kdeunstable/qbluez/build/autotests/adaptertest 4: Test timeout computed to be: 9.99988e+06 4: * Start testing of AdapterTest * 4: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 4: QWARN : AdapterTest::initTestCase() QBluez: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.171 (uid=1003 pid=11623 comm=/home/kdeunstable/qbluez/build/autotests/adapterte) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=514 comm=/usr/sbin/bluetoothd ) 4: FAIL! : AdapterTest::initTestCase() '!initJob-error()' returned FALSE. () 4:Loc: [/home/kdeunstable/qbluez/autotests/adaptertest.cpp(71)] 4: PASS : AdapterTest::cleanupTestCase() 4: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 4: * Finished testing of AdapterTest * 4/6 Test #4: qbluez-adaptertest ...***Failed0.01 sec test 5 Start 5: qbluez-devicetest 5: Test command: /home/kdeunstable/qbluez/build/autotests/devicetest 5: Test timeout computed to be: 9.99988e+06 5: * Start testing of DeviceTest * 5: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 5: QWARN : DeviceTest::initTestCase() QBluez: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.172 (uid=1003 pid=11624 comm=/home/kdeunstable/qbluez/build/autotests/devicetes) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=514 comm=/usr/sbin/bluetoothd ) 5: FAIL! : DeviceTest::initTestCase() '!initJob-error()' returned FALSE. () 5:Loc: [/home/kdeunstable/qbluez/autotests/devicetest.cpp(91)] 5: PASS : DeviceTest::cleanupTestCase() 5: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 5: * Finished testing of DeviceTest * 5/6 Test #5: qbluez-devicetest ***Failed0.01 sec test 6 Start 6: qbluez-jobstest Any idea? Cheers, Albert Thanks, David On Mon, Feb 16, 2015 at 11:51 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 16 de febrer de 2015, a les 10:40
Re: Review request: QBluez
That would work i guess, note it's not only about the project name, but also about the class names. Sure. But i get two others to fail Any idea? Hmm, I would say that it is actually expected to fail if there is an error when calling GetManagedObjects on org.freedesktop.DBus.ObjectManager. By any chance, are you running Bluez 4? It doesn't have the DBus ObjectManager, so that call should fail like that. David On Tue, Feb 17, 2015 at 10:23 PM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 17 de febrer de 2015, a les 10:36:59, David Rosca va escriure: Using Q* is usually frowned upon since the Qt people have made it quick clear that they reserve the right to use Q* names themselves, i'd look for a new name. I see. What about renaming it to BluezQt? That would work i guess, note it's not only about the project name, but also about the class names. Also tried to run the tests and qbluez-managertest seems to get stuck forever. Does it take much to run? Does it need that i actually have bluetooth hardware? Tests are running with both real org.bluez (system bus) and fake org.qbluez.bluez (session bus). You don't need to have any bluetooth hardware, nor Bluez installed at all to run the tests. The reason why it hangs is probably that fakebluez cannot, for some reason, start. I have pushed a change that fixes the hang, and also show some info why it cannot start. Can you please send me the output of qbluez-managertest? Now it doesnt' fail :D But i get two others to fail 4: Test command: /home/kdeunstable/qbluez/build/autotests/adaptertest 4: Test timeout computed to be: 9.99988e+06 4: * Start testing of AdapterTest * 4: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 4: QWARN : AdapterTest::initTestCase() QBluez: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.171 (uid=1003 pid=11623 comm=/home/kdeunstable/qbluez/build/autotests/adapterte) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=514 comm=/usr/sbin/bluetoothd ) 4: FAIL! : AdapterTest::initTestCase() '!initJob-error()' returned FALSE. () 4:Loc: [/home/kdeunstable/qbluez/autotests/adaptertest.cpp(71)] 4: PASS : AdapterTest::cleanupTestCase() 4: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 4: * Finished testing of AdapterTest * 4/6 Test #4: qbluez-adaptertest ...***Failed0.01 sec test 5 Start 5: qbluez-devicetest 5: Test command: /home/kdeunstable/qbluez/build/autotests/devicetest 5: Test timeout computed to be: 9.99988e+06 5: * Start testing of DeviceTest * 5: Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2) 5: QWARN : DeviceTest::initTestCase() QBluez: GetManagerJob Error: Rejected send message, 2 matched rules; type=method_call, sender=:1.172 (uid=1003 pid=11624 comm=/home/kdeunstable/qbluez/build/autotests/devicetes) interface=org.freedesktop.DBus.ObjectManager member=GetManagedObjects error name=(unset) requested_reply=0 destination=org.bluez (uid=0 pid=514 comm=/usr/sbin/bluetoothd ) 5: FAIL! : DeviceTest::initTestCase() '!initJob-error()' returned FALSE. () 5:Loc: [/home/kdeunstable/qbluez/autotests/devicetest.cpp(91)] 5: PASS : DeviceTest::cleanupTestCase() 5: Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted 5: * Finished testing of DeviceTest * 5/6 Test #5: qbluez-devicetest ***Failed0.01 sec test 6 Start 6: qbluez-jobstest Any idea? Cheers, Albert Thanks, David On Mon, Feb 16, 2015 at 11:51 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 16 de febrer de 2015, a les 10:40:44, David Rosca va escriure: Hi all, I'd like to ask for a review of the QBluez library [1]. Using Q* is usually frowned upon since the Qt people have made it quick clear that they reserve the right to use Q* names themselves, i'd look for a new name. Also tried to run the tests and qbluez-managertest seems to get stuck forever. Does it take much to run? Does it need that i actually have bluetooth hardware? Cheers, Albert QBluez is a Qt 5 wrapper for Bluez 5 DBus API. I have started working on it as a GSoC 2014 project. It is intended to be a libbluedevil replacement, main difference being that every DBus call is made asynchronous. It also exposes more Bluez API than libbluedevil, including Obex API. This library will be used in Bluedevil frameworks branch. I have also written a new Bluetooth plasmoid [2] that uses a QBluez QML plugin. Bellow is a list of some additional QBluez features compared to libbluedevil: * it is a tier 1 framework * asynchronous API using jobs/pending calls with possibility
Review request: QBluez
Hi all, I'd like to ask for a review of the QBluez library [1]. QBluez is a Qt 5 wrapper for Bluez 5 DBus API. I have started working on it as a GSoC 2014 project. It is intended to be a libbluedevil replacement, main difference being that every DBus call is made asynchronous. It also exposes more Bluez API than libbluedevil, including Obex API. This library will be used in Bluedevil frameworks branch. I have also written a new Bluetooth plasmoid [2] that uses a QBluez QML plugin. Bellow is a list of some additional QBluez features compared to libbluedevil: * it is a tier 1 framework * asynchronous API using jobs/pending calls with possibility to run synchronously (for tests/cli apps) * extended API - this currently includes API for Obex File Transfer, Obex Object Push and Profile API for implementing Bluetooth profiles * build-time optional QML plugin - currently exposing Manager, Adapter, Device, DevicesModel and PendingCall * possibility to be notified when method call finishes and to be notified about possible errors Currently, there is a qbluez branch in Bluedevil [3]. It will be merged to frameworks branch once QBluez is reviewed. You can find generated documentation here [4]. Thanks, David Rosca [1] http://quickgit.kde.org/?p=scratch%2Fdrosca%2Fqbluez.git [2] https://github.com/nowrep/qbluez-plasmoid [3] https://projects.kde.org/projects/kde/workspace/bluedevil/repository/show?rev=qbluez [4] http://david.rosca.cz/qbluez-apidoc/html/
