Closed pvonmoradi closed 1 month ago
blueman: 2.3.5-2 BlueZ: 5.66-1 Distribution: Debian 12 Desktop environment: i3wm (no DE), dunst notification daemon
According to Wiki, blueman defers the yes/no confirmation for various bluetooth services to the notification daemon. But what happens when the daemon doesn't support "buttons"?
Dunst should support actions.
Since blueman already uses gtk, shouldn't it present the yes/no confirmation UI with a normal gtk dialog too (why it defers this task to third-party notification daemons)?
Blueman has a Gtk Dialog fallback if there is no notification daemon available.
For example I had trouble pairing with an Android device since I couldn't confirm the code on desktop side. I had to resort to
bluetoothctl
then runscan on
andpair MAC_ADDRESS
.
Post the blueman-applet log when you attempt to pair (or some other action that requires a notification). See https://github.com/blueman-project/blueman/wiki/Troubleshooting#debugging-blueman how to.
Most of the issues with dunst have been due some misconfigured/broken system. When we see the blueman-applet log we can see what happened.
blueman: 2.3.5-2 BlueZ: 5.66-1 Distribution: Debian 12 Desktop environment: i3wm (no DE), dunst notification daemon
According to Wiki, blueman defers the yes/no confirmation for various bluetooth services to the notification daemon. But what happens when the daemon doesn't support "buttons"? Since blueman already uses gtk, shouldn't it present the yes/no confirmation UI with a normal gtk dialog too (why it defers this task to third-party notification daemons)?
For example I had trouble pairing with an Android device since I couldn't confirm the code on desktop side. I had to resort to
bluetoothctl
then runscan on
andpair MAC_ADDRESS
.Same issue when receiving a file from the paired device (I have to
trust
the device and enableAccept files from trusted devices
option to be able to receive anything at all)