On Sun, Aug 20, 2006 at 02:19:44PM +0200, Hendrik Sattler wrote: > That would mean that the bluez guys acutally documented those dbus messages > (did they? If yes, where?). > And that the dbus documentation gets to a usuable state (just naming the > functions is not a documentation).
you might want to look at http://bluez.cvs.sourceforge.net/bluez/utils/hcid/dbus-api.txt?revision=1.41&view=markup > > The situation is actually sad: bluetooth on the desktop was working fine and > nice and it all broke close to release (with no obvious gain). I stand corrected, there's an updated pin helper in bluez cvs, it is for gnome using dbus bindings and glib. I'll look into it. http://bluez.cvs.sourceforge.net/bluez/gnome/ > I propose a solution: > Provide a wrapper that can call old pinhelpers and listens to dbus, like > "bluez-pinhelper-wrap /usr/lib/kdebluetooth/kbluepin" > That would at least bring the previous situation back and provide backward > compatibility of some kind (the user would have to start the above command). > If that was you intention with passkey-agent: there is no documenation on how > to actually use it (what is the agent-path? even looking at the source code, > I do not get what it shall do). the point of add-passkey/register-passkeys is to provide basic functionality without requiring X. I actually like the wrapper idea but first let's see what the new gnome helper can do. Also, how much work is required in fixing the kde part? thanks, filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
signature.asc
Description: Digital signature
