Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
Still no decorations (with Gtk.MessageDialog(decorated=True).show() followed by Gtk.main()) So you cannot even force decorations? Wow, weird. Okay, so this is probably some sort of GTK / Xfce4 problem? Should I report it against some other package (which?), or reassign this report? Well, your tests where not blueman specific. I don't know what it could be. Might be some configuration or something. I'd say the problem sits somewhere between / in GTK and xfwm, yes.
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
On Mon, 11 Jul 2022 09:53:50 +0200 Christopher Schramm wrote: > Alright, so... > > according to your first test and as expected a notification daemon does > not seem to be available. According to your report, you do have > notification-daemon installed, so running > /usr/lib/notification-daemon/notification-daemon in your desktop session > should solve that. Desktop environments often include a specific daemon. > notification-daemon is Gnome's. Plasma, Xfce, LxQt, MATE, Cinnamon etc. > have their own and the respective packages all provide > notification-daemon, see > https://packages.debian.org/bookworm/notification-daemon. A common > choice by folks on i3 and similar is dunst. Thanks for the explanation - I'm using Xfce4, so I guess I'd want xfce4-notifyd > As no notification daemon seems to be running, blueman uses its fallback > and shows a GTK MessageDialog. Just like any GTK window, they should get > decorated by the window manager by default. A simple test in Python (run > with python3 -c as before or just in the interactive interpreter), > independent of blueman: > > from gi.repository import Gtk > Gtk.MessageDialog().show() > Gtk.main() No decorations. > Boiled down to a GTK Window (MessageDialog is a special case of a Window): > > from gi.repository import Gtk > Gtk.Window().show() > Gtk.main() Decorations. > Both should show decorations, as that's the default > (https://docs.gtk.org/gtk3/method.Window.set_decorated.html). I can > force missing decoration with: > > from gi.repository import Gtk > Gtk.Window(decorated=False).show() > Gtk.main() > > Maybe you can make it work with the opposite: > > from gi.repository import Gtk > Gtk.Window(decorated=True).show() > Gtk.main() Still no decorations (with Gtk.MessageDialog(decorated=True).show() followed by Gtk.main()) > That's totally unexpected, though, and you seem to have a more generic > issue between GTK and your window manager, unrelated to blueman. Okay, so this is probably some sort of GTK / Xfce4 problem? Should I report it against some other package (which?), or reassign this report? -- Celejar
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
Alright, so... according to your first test and as expected a notification daemon does not seem to be available. According to your report, you do have notification-daemon installed, so running /usr/lib/notification-daemon/notification-daemon in your desktop session should solve that. Desktop environments often include a specific daemon. notification-daemon is Gnome's. Plasma, Xfce, LxQt, MATE, Cinnamon etc. have their own and the respective packages all provide notification-daemon, see https://packages.debian.org/bookworm/notification-daemon. A common choice by folks on i3 and similar is dunst. As no notification daemon seems to be running, blueman uses its fallback and shows a GTK MessageDialog. Just like any GTK window, they should get decorated by the window manager by default. A simple test in Python (run with python3 -c as before or just in the interactive interpreter), independent of blueman: from gi.repository import Gtk Gtk.MessageDialog().show() Gtk.main() Boiled down to a GTK Window (MessageDialog is a special case of a Window): from gi.repository import Gtk Gtk.Window().show() Gtk.main() Both should show decorations, as that's the default (https://docs.gtk.org/gtk3/method.Window.set_decorated.html). I can force missing decoration with: from gi.repository import Gtk Gtk.Window(decorated=False).show() Gtk.main() Maybe you can make it work with the opposite: from gi.repository import Gtk Gtk.Window(decorated=True).show() Gtk.main() That's totally unexpected, though, and you seem to have a more generic issue between GTK and your window manager, unrelated to blueman.
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
On Wed, 6 Jul 2022 23:44:21 +0200
Christopher Schramm wrote:
> > Shouldn't
> > there be some sort of "Okay" button, or some window decoration that
> > allows them to be closed?
>
> Yes, window decorations are expected if those are the fallback windows.
> They are GTK MessageDialogs which by default shall get decorated by the
> window manager.
>
> Another possibility would be that what you see is generated by some kind
> of notification daemon.
>
> You can test both facilities to check:
>
> Standard notification (default):
>
> python3 -c 'from blueman.gui.Notification import _NotificationBubble as
> Notification; Notification("Test", "Test").show()'
~$ python3 -c 'from blueman.gui.Notification import _NotificationBubble as
Notification; Notification("Test", "Test").show()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/blueman/gui/Notification.py", line 193,
in __init__
self._capabilities = self.GetCapabilities()
File "/usr/lib/python3/dist-packages/gi/overrides/Gio.py", line 349, in
__call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.GError: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Notifications was not provided by any .service files (2)
(No window appears.}
> Dialog (fallback):
>
> python3 -c 'from blueman.gui.Notification import _NotificationDialog as
> Notification; Notification("Test", "Test").show(); from gi.repository
> import GLib; GLib.MainLoop().run()'
~$ python3 -c 'from blueman.gui.Notification import _NotificationDialog as
Notification; Notification("Test", "Test").show(); from gi.repository import
GLib; GLib.MainLoop().run()'
^CTraceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/gi/overrides/GLib.py", line 495, in run
with register_sigint_fallback(self.quit):
File "/usr/lib/python3.10/contextlib.py", line 142, in __exit__
next(self.gen)
File "/usr/lib/python3/dist-packages/gi/_ossighelper.py", line 237, in
register_sigint_fallback
signal.default_int_handler(signal.SIGINT, None)
KeyboardInterrupt
(Window appears, looking much like the ones I filed this report about -
no decorations or any obvious means of closing.)
I realized, BTW, that the easy way to close these windows is ALT-F4
when they have focus, but I still think they should have some labeled
method of closing / dismissal.
I really don't know much about notification daemons and fallback
windows. What expected pieces are my system missing?
--
Celejar
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
Shouldn't
there be some sort of "Okay" button, or some window decoration that
allows them to be closed?
Yes, window decorations are expected if those are the fallback windows.
They are GTK MessageDialogs which by default shall get decorated by the
window manager.
Another possibility would be that what you see is generated by some kind
of notification daemon.
You can test both facilities to check:
Standard notification (default):
python3 -c 'from blueman.gui.Notification import _NotificationBubble as
Notification; Notification("Test", "Test").show()'
Dialog (fallback):
python3 -c 'from blueman.gui.Notification import _NotificationDialog as
Notification; Notification("Test", "Test").show(); from gi.repository
import GLib; GLib.MainLoop().run()'
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
On Mon, 4 Jul 2022 17:18:33 +0200 Christopher Schramm wrote: > Those popup windows are a fallback for when the required > notification-daemon does not work. blueman is intended to be used with a > running notification-daemon. I have no problem with such popups - but they should be *somehow* dismissable! I currently have six of them on my desktop, they have been there for days, and I have no idea how to make them go away! Shouldn't there be some sort of "Okay" button, or some window decoration that allows them to be closed? -- Celejar
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
Those popup windows are a fallback for when the required notification-daemon does not work. blueman is intended to be used with a running notification-daemon.
Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows
Package: blueman Version: 2.2.5-1 Severity: normal Blueman leaves stray "Connected" and "Disconnected" popup windows, with no buttons or obvious means of dismissal, on my desktop. I have attached an example. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blueman depends on: ii adwaita-icon-theme42.0-2 ii bluez 5.64-2 ii bluez-obexd 5.64-2 ii dbus 1.14.0-1 ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-ayatanaappindicator3-0.1 0.5.91-1 ii gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1 ii gir1.2-glib-2.0 1.72.0-1+b1 ii gir1.2-gtk-3.03.24.34-1 ii gir1.2-nm-1.0 1.38.2-1 ii gir1.2-pango-1.0 1.50.7+ds-1 ii libbluetooth3 5.64-2 ii libc6 2.33-7 ii libpulse-mainloop-glib0 15.0+dfsg1-4+b1 ii librsvg2-common 2.54.4+dfsg-1 ii notification-daemon 3.20.0-4+b1 ii policykit-1 0.105-33 ii python3 3.10.4-1+b1 ii python3-cairo 1.20.1-3 ii python3-gi3.42.1-1 ii python3-gi-cairo 3.42.1-1 Versions of packages blueman recommends: ii pulseaudio-module-bluetooth 15.0+dfsg1-4+b1 blueman suggests no packages. -- no debconf information
