Disable/remove "Notify about volume changes with keyboard" on Wayland

[stefonarch]

As title. "Show always notifications" is working normally.

Steps to Reproduce (for bugs)

1. Set the hook on "Notify about volume changes with keyboard"
2. Use the shortcuts
3. Nothing is shown

System Information

• LXQt Version: git
• Distribution & Version: arch, debian
• Compositors: labwc, wayfire

[stefonarch]

This probably depends as lxqt-globalkeysd can't register keys under wayland yet. Keyboard shortcuts are all set by compositors config files atm.

[stefonarch]

It would work using dbus: qdbus org.kde.StatusNotifierWatcher /global_key_shortcuts/panel/volume2/mute org.lxqt.global_key_shortcuts.client.activated for example but we have the numbering issue - we cannot know if the panel has changed.

[tsujan]

As you surely know, lxqt-globalkeysd isn't for Wayland.

[stefonarch]

It's still an issue IMO, because we have this setting in the GUI and it doesn't work on Wayland. So it should be greyed out at least.

[tsujan]

I just cleaned up the issues list a little, for more important ones to become visible. Changing its title and reopening ...

[stefonarch]

It's still to grey out under Wayland. It's possible to use external agents to show an OSD at volume changes by keyboard:

1. https://github.com/heyjuvi/avizo

• Add avizo-service to autostart
• Use volumectl -|+|% or wpctl in the XF86Audio* shortcuts in the compositor.

2. using wob, requires more fiddling but will work too.

[isf63]

Does Wayland have a protocol for registering key bindings?

[stefonarch]

Not really, see the main discussion https://github.com/lxqt/lxqt-globalkeys/issues/282

[tsujan]

IMO, we shouldn't disable it under Wayland. The user can add shortcuts for

qdbus6 org.kde.StatusNotifierWatcher /global_key_shortcuts/panel/volume/up org.lxqt.global_key_shortcuts.client.activated

and

qdbus6 org.kde.StatusNotifierWatcher /global_key_shortcuts/panel/volume/down org.lxqt.global_key_shortcuts.client.activated

I know that it may be "volumeX", but that makes no difference.

EDIT: Don't underestimate what users can do with D-BUS under Wayland ;)

[stefonarch]

Don't overestimate users... they see an option which doesn't work and will be frightened by such commands ;)

It's not about changing volume from keyboard which works out of the box on all our compositors except kwin_wayland (by using wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle and similar but any command could be used including this qdbus ones). It' about this box which cannot be shown on Wayland when changing volume by keyboard by those types of shortcuts.

[tsujan]

It' about this box which cannot be shown on Wayland when changing volume by keyboard

That box is the tooltip. This is about showing notifications.

[stefonarch]

Oops, I was sure the tooltip was shown with that setting and not a regular notification.

But using by default the qdbus shortcut isn't feasible - as soon users change their panels it won't work anymore. So it's still valid IMO: we have a settings which doesn't do anything on Wayland.

[tsujan]

I don't remember X11 — extra things can be done under it — but that setting is about notifications and works like a charm on Wayland.

Don't overestimate users…

In Linux we don't consider users stupid. That's why Windows refugees suddenly feel like gurus when they come to Linux ;)

[stefonarch]

I don't remember X11 — extra things can be done under it — but that setting is about notifications and works like a charm on Wayland.

"Notify volume changes with keyboard" does not work under Wayland, as setting. It works if you use that dbus command but that's independent of that setting. "Notify always" does.

[tsujan]

The point is that it can be used on Wayland. Disabling it would mean depriving users of it; we should not do that.

[tsujan]

It works if you use that dbus command but that's independent of that setting.

If I uncheck "Notify about volume changes with keyboard" and use the D-BUS command, no notification will be shown. Isn't it so for you? I'm on labwc.

[stefonarch]

I see, then the setting is respected. But telling users to find out their correct path to use it is the same as telling them to use avizo. It's a setting which cannot work out of the box, unless we find a way to have a dbus command catchall.

[tsujan]

If you insist on guiding users, what about a tooltip that says "Effective on Wayland only with a D-BUS shortcut"? Advanced users will get it. But I think you'd agree that we shouldn't deprive (advanced or above average) users of something that ordinary users may not want to deal with.

[tsujan]

unless we find a way to have a dbus command catchall.

Qt QDBusViewer exists for that reason.

EDIT: Its command is qdbusviewer6. It had a desktop entry with Qt4; I made a Qt6 one for myself:

[Desktop Entry]
Name=Qt6 QDBusViewer
GenericName=D-Bus Debugger
Comment=Debug D-Bus applications
Exec=qdbusviewer6
Icon=qdbusviewer
Terminal=false
Type=Application
Categories=Qt;Development;Debugger;

EDIT2: Oops! qt6-tools includes a desktop entry — in Arch at least.

[stefonarch]

To get the paths easier using qdbus6 org.kde.StatusNotifierWatcher then to navigate the GUI.

Anyway I was thinking of a way that works always (volume|volume2|volumeX):

#!/bin/sh
# actions: up|down|mute(=toggle mute)
action=$1
volume=$(qdbus6 org.kde.StatusNotifierWatcher | grep volume | head -n1)

qdbus6 org.kde.StatusNotifierWatcher $volume/$action org.lxqt.global_key_shortcuts.client.activated

Saving that as "volume" in $PATH it can be used in the Wayland settings for XF86AUDIO* commands (similar script for opening mainmenu or fancymenu can be made too).

[stefonarch]

I think the only "clean" way if solving this is shipping a sort of lxqt-qdbus script in lxqt-wayland-session with the above code and other code for

• open fancy menu
• open applications by shortcut inside lxqt-session