Update passkey message instead of closing and recreating notification

[coyotebush]

Closing and recreating the notification was particularly problematic in the context of the Qubes OS notification proxy not supporting CloseNotification, but even with just xfce4-notifyd or the fallback dialog, it causes flickering. By now the notification code now supports set_message for a better approach. But only update a previous passkey notification and not potentially a notification that has actions.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[infirit]

I don't think we need a dedicated notification for this. Does 447102b work for you? I tested this on plasma and it works fine there.

[coyotebush]

I tried that first. The only issue would be that if self._notification was most recently assigned in _on_request_confirmation, it would retain action buttons. Presumably in practice bluez will invoke Cancel (or connect the device) in between, but relying on that feels a little fragile. The original Qubes OS bug report would have reached that state due to CloseNotification raising an exception, and I can certainly also reach that state with manual dbus-send calls.

[infirit]

I see we don't actually check if the notification daemon supports actions in _on_request_confirmation which is a bug which we need to fix.

I assume your notification daemon doesn't support actions. Do you advertise you support actions?

edit: Although I'm not sure if we can then use a notification for _on_request_confirmation if actions are not supported.

[coyotebush]

The Qubes proxy supports actions and advertises such. And Notification.py would fall back to a dialog otherwise, which I suppose would appear even stranger if reused for a passkey.

blueman/blueman/gui/Notification.py

Lines 296 to 301 in 9cb3c11

	if forced_fallback or 'body' not in caps or (actions and 'actions' not in caps):
	# Use fallback in the case:
	# * user does not want to use a notification daemon
	# * the notification daemon is not available
	# * we have to show actions and the notification daemon does not provide them
	klass: type[_NotificationBubble | _NotificationDialog] = _NotificationDialog