2006
7
Sep
7
Sep
After being a bit disappointed that Bluez-utils 3.x simply doesn't accept old pin-helpers, like kbluepin from kdebluetooth, i thought about the best solution for this.
Of course, we should develop a new pin helper, which can communicate with bluez over dbus.. and with kde4 supporting dbus it will be very easy.. but in the meantime, you can enjoy this patch.
It modify the standard pin agent, so that, instead of giving it the pin as argument, you can give it the path of the pin-helper to execute.
I'm using it in the new version of the live cd of kmobiletools.
Hope you like it!
- rockman's blog
- Login or register to post comments
- 814 reads
Syndicate Blogs
Comments
Solid?
Shouldn't a large part of KMobileTools be made a part of the Solid layer for KDE4?
Well.. maybe.. Currently i
Well.. maybe..
Currently i developed a ready_to_libs "QSerial" class that allows accessing a serial device in a similar way to QFile. Of course it works also with "virtual" serial ports, like USB/ACM and bluetooth rfcomm.
But what else did you meant with "a large part of KMobileTools"?
Solid...
I mean separating out everything that deals with the hardware devices (phones and their connections) into a library that is made part of Solid. A cell phone abstraction library that could be accessed by any KDE application and queried for the presence and capabilities of available cell phones, as well as asked to perform tasks on them. The GUI part of KMobileTools could then be built on top of this, but also other tools would talk directly to the library; e.g. KAddressbook could display the option "Call this contact on my Ericsson phone" whenever such a phone is within Bluetooth range.
I didn't study the KMobileTools code, so this is just an uneducated suggestion, but it seems to me to be in line with the idea of Solid; a common layer to interface with hardware, regardless of whether based on HAL or other mechanisms.