Open bucccket opened 1 year ago
blueman depends on a notification daemon to be present. Unfortunately I do not see that expressed in the Arch package. A typical choice by users of (I'll frame it as...) tiling window managers is dunst.
In case of unexpected unavailability of a notification daemon, blueman uses a window-based fallback. We do not put much love into that, to be honest. I actually regularly consider removing it completely. Quickly testing the window, apart from decorations, task bar etc. I am able to close it with Esc.
I'll add accels like we did for the other windows.
dunst is exactly what I needed! I totally forgot to install a notification daemon on this machine! Thanks a lot and I'm glad you'll look into this
I actually regularly consider removing it completely.
:+1:
I'm here because I'm fed up with those windows appear at all when I deliberately have turned off the ConnectionNotifier plugin.
If you decide not to rip out the window based fallback mechanism, it should at least follow the dictates of the ConnectionNotifier plugin. Unless I've misunderstood the intent of that mechanism too :)
Thanks for all the work put in to getting bluetooth usable on Linux \o/
I'm now off to try dunst
for size :)
Hmmn. ConnectionNotifier being enabled/disabled makes no difference to whether or not notifications are displayed when using dunst
here - they're always displayed.
blueman: 2.3.5-2 BlueZ: 5.86-1 Distribution: Arch Linux x86_64 Desktop environment: DWM
Log file at https://pastebin.com/bmpbzPLb
Whenever I use the
Connect
/Disconnect
option on a listed device, a small popup window shows as intended, yet it will not disappear after showing up. This forces me, to kill the applet via htop. It happens regardless of device and whether the connection was successful or not.