blueman-applet logs exception in GameControllerWakelock on wayland

[jokeyrhyme]

blueman: 2.1.4 BlueZ: 5.55 Distribution: Archlinux Desktop environment: swaywm (wayland, no X11)

• [X] I have consulted the Troubleshooting page and done my best effort to follow.

Howdie, I hope you are well, thanks for this extremely useful project :+1:

I've been noticing some python exceptions in my logs, and finally tracked them down to blueman-applet:

blueman-applet version 2.1.4 starting
Stale PID, overwriting
blueman-applet 07.51.52 ERROR    PluginManager:91 load_plugin: Unable to load plugin module GameControllerWakelock
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/blueman/main/PluginManager.py", line 89, in load_plugin
    importlib.import_module(self.module_path.__name__ + ".%s" % plugin)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/lib/python3.9/site-packages/blueman/plugins/applet/GameControllerWakelock.py", line 14, in <module>
    raise ImportError('This is not an X11 screen')
ImportError: This is not an X11 screen
blueman-applet 07.51.52 WARNING  PluginManager:148 __load_plugin: Not loading DhcpClient because its conflict has higher priority
blueman-tray version 2.1.4 starting
blueman-applet 07.51.52 WARNING  PluginManager:148 __load_plugin: Not loading PPPSupport because its conflict has higher priority

This is not at all urgent for me, as blueman is doing it's job very well for my use case

I guess I just wanted to surface this in case there was a serious issue here, or if there was a discussion to be had about the plugin execution flow: should GameControllerWakelock be updated to work with wayland? Should the plugin loader understand that some plugins are for X11-only and skip even attempting to such plugins (with a clean non-exception WARNING message as for DhcpClient and PPPSupport)?

[infirit]

The ImportError is raised intentionally as the plugin only works with X11 (root window). We only have one plugin that doesn't work with Wayland so adding logic for this does not make sense :smile:.

At some point it should start using dbus, org.freedesktop.ScreenSaver which does not rely on the X11. If you are up for it feel free to fork :wink:.

[cschramm]

I think we could use GTK+ power, namely gtk_application_inhibit with GTK_APPLICATION_INHIBIT_IDLE and gtk_application_uninhibit. To my understanding it would save us from the X11 interaction as GTK+ will route it to either its X11 backend or its Wayland backend where it's a noop and since 3.99.0 it even implements the idle-inhibit Wayland protocol (https://gitlab.gnome.org/GNOME/gtk/-/commit/5af7d6bff3d2920aca118a36f13b23cbb68c1641#a64185fe139cee5b6c20bff1d9e5e985a228410f) that should get it working in Wayland as well.

I don't know who implements org.freedesktop.ScreenSaver but it seems to be coupled with that protocol and I'm not sure if using it directly and exclusively is a good fit as it seems to be implemented only by DEs that support Wayland (except Gnome :shrug:) and I e.g. don't seem to have it at all on my MATE system.

Regarding the ImportError it is intentional and it is used in other plugins as well (at least AppIndicator and KillSwitch) to indicate "cannot be used" situations but it would make total sense to use our own dedicated exception for that and print something nicer than a full-blown error with traceback.

[danielmorlock]

The ImportError is raised intentionally as the plugin only works with X11 (root window). We only have one plugin that doesn't work with Wayland so adding logic for this does not make sense .

At some point it should start using dbus, org.freedesktop.ScreenSaver which does not rely on the X11. If you are up for it feel free to fork .

Does this mean that currently there is no support to run the blueman applet in Wayland compositor e.g. like sway?

[jokeyrhyme]

Does this mean that currently there is no support to run the blueman applet in Wayland compositor e.g. like sway?

It definitely works, I'm using it right now whilst typing this comment: sway + waybar + blueman-applet

I originally raised this issue asking about error log output whilst doing so, blueman and blueman-applet otherwise seem to function as expected

[danielmorlock]

Does this mean that currently there is no support to run the blueman applet in Wayland compositor e.g. like sway?

It definitely works, I'm using it right now whilst typing this comment: sway + waybar + blueman-applet

I originally raised this issue asking about error log output whilst doing so, blueman and blueman-applet otherwise seem to function as expected

Thanks for this info, blueman applet is now working for me, too. I needed to build it with appindicator flag enabled. According to https://github.com/blueman-project/blueman/issues/1371, this is required to use libappindicator/SNI which is required for using it in wayland.