Happy New Year 2007. Am Sonntag 31 Dezember 2006 16:22 schrieb Marcel Holtmann: > > * plugging the dongle in and then chaning to "connectable" may be too > > late Practically the same thing as the default from above. > > This is why we go back to non-discoverable after 180 seconds by default. > > Supporting these kind of strange setting would also mean that you know > the address of the adapter you are gonna plug in up-front. In general > you don't. Except you really know what you are doing and then no > interface will fully suit you at all.
Well, it is a special case, I agree. But since you already plugged it in once, you can already know the address (ls /var/lib/bluetooth). > > > > So is there an easy command line tool for all those dbus options > > > > (except using raw dbus command)?: no == very bad usibility (and an > > > > awful lot to type for one option) > > > > > > > > So how can you solve this problem with your input: > > > > * ship the dbus API documenation in the binary packages > > > > > > Definitely. > > > > > > > * give the user and root a shell tool to make use of the things in > > > > the bluez dbus API without getting bloody hands by using dbus-send > > > > > > Since we wanna avoid a Python dependency, > > > > Does that mean that there is such a tool? > > The apitest script could easily do this job or the dbusdef.py pre-load > code are really helpful for testing. In general it is really simple to > handle our D-Bus API from within Python. Most things are only a few > lines of Python, but for a base package like bluez-utils you don't wanna > have that dependency. Pythong is priority standard. Ok not essential but looking at what already depends on python, it is most likely already installed. I wouldn't mind it but I am not the bluez-utils maintainer ;) HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
