> 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, Jo
Done. It's in kdereview now:
https://projects.kde.org/projects/kdereview/bluez-qt
David
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 b
Please file a sysadmin request to move it into kdereview, then after a
couple of weeks if there's no objections it can be moved into
kde/workspace (for plasma).
Jonathan
On Wed, Mar 11, 2015 at 6:49 PM, Jonathan Riddell 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
On Mon, Feb 16, 2015 at 10:40:44AM +0100, David Rosca wrote:
> Hi all,
> I'd like to ask for a review of the QBluez library [1].
Looks like you've been working hard :)
The name KF5BluezQt seems inelegant, is has both a prefix and a suffix, how
about just KF5Bluez ?
The headers get installed int
El Diumenge, 1 de març de 2015, a les 23:15:36, David Rosca va escriure:
> 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 b
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 playgr
> 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
GetManagedObje
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 w
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/kdeunstabl
> 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.
I have also renamed the library to BluezQt. Here is an updated
documentation: http://david.rosca.cz/bluezqt-apidocs/html/
David
On Wed,
> 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
> 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
> 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 Blu
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 expecte
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 f
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
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
On Monday 16 February 2015 23:51:17 Albert Astals Cid wrote:
> > 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.
Unless,
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
21 matches
Mail list logo
