Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows

[Christopher Schramm]

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.

[Celejar]

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

[Christopher Schramm]

> 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()'

[Celejar]

On Wed, 6 Jul 2022 23:44:21 +0200
Christopher Schramm <deb...@cschramm.eu> 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 "<string>", line 1, in <module>
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 "<string>", line 1, in <module>
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

[Christopher Schramm]

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.

[Celejar]

On Mon, 11 Jul 2022 09:53:50 +0200
Christopher Schramm <deb...@cschramm.eu> 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

[Christopher Schramm]

> 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.