Am Sonntag 31 Dezember 2006 15:40 schrieb Marcel Holtmann: > > The administrator should be able to change the default (visibility or > > not) or there should be an always working default. > > The default is not visible (due security reasons) and if you decide it > to switch it to visible (even with a low-level HCI command) it will only > stay visible for 180 seconds. That is the default starting with 3.x.
Taking that... > > That is currently not the case because the bluetooth guys change stuff > > but the user frontends do catch up a bit late. Just remember the passkey > > situation and this is pretty much the same. It probably gets solved in > > the long run but that's a strange idea of development :-/ > > It is actually solved for all GNOME and command line users. I don't know > about the KDE guys, but I am sure they have something similar. They don't, yet, users possibly have to wait for KDE4. What is the solution for command line users? Or do you mean dbus-send? > > Beside that, running the dbus command suggested in this bug report works, > > too. It should be noted, though, that you have to be root. > > No. You have to be console user (or root). Sorry but that is not sufficient. I tested this (X with konsole) and nothing happened. Running the same command with su worked. > > It probably is the better alternative with exceptions: > > * you cannot change the mode of devices that are currently not plugged in > > That is true. The case to change settings for not active devices is > kinda strange. I know that there might be corner cases, but I never > fully got convinced that this is needed. * your last mode was "discoverable" * you do not want to be visible * plugging the dongle in and then chaning to "connectable" may be too late Practically the same thing as the default from above. > > * you can only refer to devices by using the device name, not the address > > Actually you can use "manager.FindAdapter(address)" to get the path for > an adapter. Remember that the path for an adapter is only a string. It > has no real meaning. You shouldn't trust that they stay the same. So it is practically useless? > > 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? > I seems that there is finally > need for a btconfig tool written in plain C. Or even better: write a libbluezconf with a shell frontend, so that other programs can easily change bluetooth settings. Wouldn't a simply shell script suffice in the mean time? HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
