Disable blueman-applet autostart in Gnome

[ispanos]

blueman: blueman.x86_64 -- 1:2.3.5-3.fc38
BlueZ: bluez.x86_64 -- 5.68-1.fc38
Distribution: Fedora 38
Desktop environment: Gnome / Swaywm

I use Blueman in Sway and I start it in the config file. However, when using Gnome, blueman applet auto-starts and I can't find a way to disable it. In case it is relevant, here is the output of systemctl --user list-units | grep blue

  sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d10-3\x2d10:1.0-bluetooth-hci0-hci0:3585.device loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:3585
  sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d10-3\x2d10:1.0-bluetooth-hci0.device           loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0
  sys-subsystem-bluetooth-devices-hci0.device                                                  loaded active plugged /sys/subsystem/bluetooth/devices/hci0
  sys-subsystem-bluetooth-devices-hci0:3585.device                                             loaded active plugged /sys/subsystem/bluetooth/devices/hci0:3585
  app-gnome-blueman-17533.scope                                                                loaded active running Application launched by gnome-session-binary
  bluetooth.target                                                                             loaded active active  Bluetooth

Thank you for your time.

P.S. I have disabled bluetooth on boot and I can't figure out how to enable using a key-bind. bluetoothctl power on works only after I first enable bluetooth using blueman or gnome settings. I would appreciate it if you could point me to the right direction.

[cschramm]

Gnome seems to use an application called Tweaks to manage "Startup Applications". You should find and have an option to disable blueman there.

Could you elaborate on "bluetoothctl power on does not work"?

[ispanos]

You should find and have an option to disable blueman there.

It is not in tweaks nor in any of the directories for autostart (~/.config/autostart $XDG_CONFIG_HOME/autostart $XDG_CONFIG_DIRS/autostart /usr/share/gnome/autostart )

$ systemctl --user disable blueman-applet
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Could you elaborate on "bluetoothctl power on does not work"?

I just restarted my laptop so I can share the output in the terminal. I have pasted some relevant information bellow. After reboot due to disabling bluetooth on boot I use blueman applet to enable it. For some reason I had totally forgotten about rfkill.

$ bluetoothctl power on
No default controller available
$ sudo bluetoothctl power on
No default controller available
$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: yes
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

$ rfkill unblock 0
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
3: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
$ bluetoothctl power on
[CHG] Controller A0:E7:0B:2A:41:48 PowerState: off-enabling
[CHG] Controller A0:E7:0B:2A:41:48 Class: 0x007c010c (8126732)
Changing power on succeeded

I want to turn on bluetooth to connect to my headset. Should I use rfkill or is there more appropriate way? (I need to be able to do it without sudo privileges.)

[cschramm]

I don't exactly know about the Fedora package, but generally blueman ships a desktop file, usually installed to /etc/xdg/autostart/blueman.desktop. Desktops pick that up for autostart by default and provide a way to disable it. Gnome's way, to my understanding, is Tweaks.

If a killswitch is enabled, rfkill is required to first get the adapter available at all, yes.

[ispanos]

/etc/xdg/autostart/blueman.desktop

Indeed this file exists. However there are also other dekstop files in that directory, e.g. nm-applet.desktop, that do not start automatically. Just to clarify, the only program that appears in gnome-tweaks autostart is dropbox, which I added manually.

[cschramm]

nm-applet.desktop typically has NotShowIn=KDE;GNOME;, so that Gnome ignores it. I have no idea why Tweaks does not pick blueman. Just tried a live system and actually had no autostart entries at all. No idea how to manage things in Gnome then. It used to have a tool called gnome-session-settings but that is long gone. Last resort is, of course, to just remove the file. 🤷‍♂️

[ispanos]

I moved it to {file}.bak in the same dir and rebooted. As expected, the applet didn't start. @cschramm Thanks for the help.

nm-applet.desktop typically has NotShowIn=KDE;GNOME;, so that Gnome ignores it.

Maybe the same should be done for blueman and gnome? It can be added in tweaks for users who want to use it in Gnome. Gnome tweaks ignores .desktop items in that directory so it's hard to figure out how it starts. Also /autostart directories are usually not used by WM users.

Curiously, my second issue with bluetoothctl power on not working after reboot is not present when blueman doesn't automatically start. I rebooted a couple more times to make sure I did anything different, but my script works when blueman is not running, meaning I can turn on bluetooth with bluetoothctl power on after reboot now that blueman doesn't automatically start. Is it something worth looking into?

Edit: blueman-applet appeared out of nowhere. I checked my dotfiles and scripts. I don't have blueman in any keybind/script.

[cschramm]

I do not really get the use case, to be honest. Why would a Gnome user even install blueman if he does not intend to use it?

The killswitch behavior makes sense. blueman-applet actually has a "KillSwitch" plugin that does exactly that

Switches Bluetooth killswitch status to match Bluetooth power state.

[ispanos]

I do not really get the use case, to be honest.

On my main laptop I have been using Swaywm for more than a year, but I will be using Gnome for some time. Thus I need blueman installed for sway, but not running when I use gnome. Also, on our share system I use Sway and my gf uses Gnome. I don't share my main laptop, but not all systems are used by a single user. It should be possible for each user do choose his/her autostart-applications.

Switches Bluetooth killswitch status to match Bluetooth power state.

Is it the same as using rfkill block ?

blueman-applet actually has a "KillSwitch" plugin that does exactly that

Does that reduce power consumption?

[cschramm]

I need blueman installed for sway, but not running when I use gnome.

That sounds rather specific and arbitrary. One could also want to start blueman on Gnome (his primary desktop) but not on another (secondary) desktop. I don't see why we should exclude it from autostart in Gnome and think autostart for all systems (that do support /etc/xdg/autostart) is a sane default. I'm sure there is a way to configure autostart on current Gnome like on any other system, although I do not see it.

Switches Bluetooth killswitch status to match Bluetooth power state.

Is it the same as using rfkill block ?

Basically yes. It blocks the kill switch when Bluetooth is powered off and unblocks it when it's powered on. ("Bluetooth is powered" is a little bit misleading as it's actually per adapter, but let's assume just a single one.)

blueman-applet actually has a "KillSwitch" plugin that does exactly that

Does that reduce power consumption?

I would not expect it to have a relevant impact. I guess the motivation for the plugin was mostly to reduce rfkill and the concept of powering adapters to just a single Bluetooth on / off state.

[ispanos]

That sounds rather specific and arbitrary. One could also want to start blueman on Gnome (his primary desktop) but not on another (secondary) desktop.

Most Sway users I know switch to Gnome when they want to game, as there significant performance gains for many games. But that is not the most important reason.

/etc/xdg/autostart doesn't work by default in Fedora workstation and is system wide. NotShowIn=GNOME; would stop auto-starting for all users and anyone can add with gnome tweaks it if its needed. It would also be better for systems with multiple users.

[cschramm]

That's not an argument for excluding Gnome, you're arguing for not shipping an autostart desktop file at all.

The standard way to disable the system-wide default is to place a user-specific file that overrides it. That'd typically go to ~/.config/blueman.desktop and you can completely disable anything by adding Hidden=true to yours. Other options are NotShowIn, OnlyShowIn etc.

[ispanos]

I am not sure what should happen because this is the first time I'm dealing with something like that.

Is that directory in /etc/xdg/autostart the proper place for blueman? I'm not asking for proof, if you are sure a yes would suffice. I'm just wondering because the rest of the desktop files there are not things that user should interact with. A tray icon, especially when for some DE it is redundant, should be easy to disable. Tray icons are not even officially supported in Gnome.

The standard way to disable the system-wide default is to place a user-specific file that overrides it. That'd typically go to ~/.config/blueman.desktop and you can completely disable anything by adding Hidden=true to yours. Other options are NotShowIn, OnlyShowIn etc.

If you keep things as is I will solve my issue by adding the file you suggest in $XDG_CONFIG_HOME/autostart/. Thank you once again for the suggestion.

My opinion is that the desktop file should be removed from /etc or the appropriate settings should be used so that it not enabled in Gnome. This is because gnome-tweaks does not show that blueman auto-starts and the only way a user can disable it is to mess with config files.

If it was present in the autostart list and you could disable it in the GUI

1. Disabling would create a file in XDG_CONFIG_HOME and everything would work as expected.
2. It would be even better

I should note that birdtray, which is a similar type of utility does not ship a .desktop icon and enabling it in the autostart menu is pretty intuitive. Sure, tweaks is not shipped by default, but neither do tray icons.

[infirit]

You should find and have an option to disable blueman there.

It is not in tweaks nor in any of the directories for autostart (~/.config/autostart $XDG_CONFIG_HOME/autostart $XDG_CONFIG_DIRS/autostart /usr/share/gnome/autostart )

$ systemctl --user disable blueman-applet
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Does it allow you to disable the service if you add

[Install]
WantedBy=multi-user.target

To /usr/lib/systemd/user/blueman-applet.service ?

[ispanos]

Does it allow you to disable the service

I don't think the service is enabled. We figured out it was the .desktop file in /etc/xdg/autostart.

[infirit]

Does it allow you to disable the service

I don't think the service is enabled. We figured out it was the .desktop file in /etc/xdg/autostart.

I'm not so sure Gnome uses it at all. But you're welcome to ignore the suggestion and I'll be happy to close the issue as solved.

[ispanos]

Does it allow you to disable the service

I don't think the service is enabled. We figured out it was the .desktop file in /etc/xdg/autostart.

I'm not so sure Gnome uses it at all. But you're welcome to ignore the suggestion and I'll be happy to close the issue as solved.

After adding

[Install]
WantedBy=multi-user.target

I checked the status.

systemctl --user status blueman-applet
○ blueman-applet.service - Bluetooth management applet
     Loaded: loaded (/usr/lib/systemd/user/blueman-applet.service; disabled; preset: disabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
             /run/user/1000/systemd/user.control/blueman-applet.service.d
             └─50-CPUWeight.conf, 50-IOWeight.conf
     Active: inactive (dead)
     
     ....

I'm not so sure Gnome uses it at all.

If you are referring to /etc/xdg/autostart it seems that it does use that path, because after removing the .desktop file blueman no longer starts.

[cschramm]

Is that directory in /etc/xdg/autostart the proper place for blueman? I'm not asking for proof, if you are sure a yes would suffice.

Yes. We assume that users want to use blueman if it's installed and blueman-applet is vital for that, especially as it acts as the agent to BlueZ. It thus needs to get auto-started and the Desktop Application Autostart Specification is the absolute standard way to achieve that and supported by most desktop environments.

A tray icon, especially when for some DE it is redundant, should be easy to disable. Tray icons are not even officially supported in Gnome.

blueman-applet is not about a tray icon. I agree that blueman is redundant for Gnome as typically gnome-bluetooth is in place and there is a chance that users of multiple desktop environments do not want to use blueman on Gnome, but there is just no NotShowInIfUserSwitchesDesktopEnvironments=Gnome.

If distributions or administrators decide to change defaults, they can always just remove or override the file, e.g. distributors might know that Gnome is not their default and thus probably not the only DE and opt in to NotShowIn=Gnome.

My opinion is that the desktop file should be removed from /etc or the appropriate settings should be used so that it not enabled in Gnome. This is because gnome-tweaks does not show that blueman auto-starts and the only way a user can disable it is to mess with config files.

I'm surprised that Gnome seems to have dropped their autostart configuration completely (while still supporting /etc/xdg/autostart). That does not make any sense to me and is in contrast to other desktops (well, to be honest, it fits the overall picture 🙈). I agree that it's unfortunate that users have to mess with config files to disable blueman on Gnome. On the other hand it would be unfortunate that users have to set up their own auto-start mechanism and Gnome (without Tweaks) does not even provide a solution. Looks like we basically need to decide if we want to provide better defaults for users that want to use blueman on Gnome or users that want to use blueman on other desktops and not on Gnome.

[ispanos]

Anyway, the rest is up to you. I don't know how other desktops work. I barely know how gnome works since it does things in a way I cannot understand.

I'm just in general someone who strongly believes in minimal system-wide configurations and easy (gui) ways to configure things for each user (on the same system) individually. Sane defaults are great, as long as they are easily configured on a per-user basis. I don't want to have to manage multiple accounts on shared computers.

[infirit]

I'm surprised that Gnome seems to have dropped their autostart configuration completely (while still supporting /etc/xdg/autostart). That does not make any sense to me and is in contrast to other desktops (well, to be honest, it fits the overall picture see_no_evil). I agree that it's unfortunate that users have to mess with config files to disable blueman on Gnome. On the other hand it would be unfortunate that users have to set up their own auto-start mechanism and Gnome (without Tweaks) does not even provide a solution. Looks like we basically need to decide if we want to provide better defaults for users that want to use blueman on Gnome or users that want to use blueman on other desktops and not on Gnome.

My gues is that it completely relies on systemd for this. There is a xdg-desktop-autostart.target which generates systemd units for these autostart desktop files. See systemctl --user list-dependencies xdg-desktop-autostart.target which for me has blueman-applet listed.

xdg-desktop-autostart.target
● ├─app-bitwarden@autostart.service
○ ├─app-blueman@autostart.service

Now, with the below unit file I am able to control blueman-applet through systemctl --user. Now the question is, should we not install the autostart desktop file when systemd is detected or should we leave this to the distribution? One thing I worry about if we handle it is how we enforce systemd starting it for every user 🤔 .

[Unit]
Description=Bluetooth management applet
PartOf=graphical-session.target

[Service]
Type=dbus
BusName=org.blueman.Applet
ExecStart=/usr/bin/blueman-applet
Restart=on-failure

[Install]
WantedBy=default.target

[cschramm]

There's also no GUI for configuring the units, is there? But yes, that eases it from files to systemctl --user. Could be a point against the autostart file (on systemd systems). 🤔

[infirit]

There's also no GUI for configuring the units, is there? But yes, that eases it from files to systemctl --user.

Plasma has it's own service things which seems unrelated to systemd but it also does not have a UI for managing this afaics.

I just made a draft PR adding the bits above to the blueman-applet unit file #2105.

[ispanos]

This has been the most constructive conversation I've had about a problem for months. Thank you for engaging. Tag me if you want me to test something.

[cschramm]

I wanted to have a look at how birdtray implements autostart, however it does not seem to provide any such configuration. 🤔 It does ship a desktop file, typically to /use/share/applications. Possibly some configuration tools pick that up and offer to set up an autostart for it. An easy configuration solution could be to add and remove a link to such an application file in the autostart directory.

[ispanos]

add and remove a link to such an application file in the autostart directory.

If it is in the home directory it would be even better.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.