Configurable shortcuts in 3.2?

Added by zz top over 11 years ago

The announcement of the 3.2 release says:

"Some keyboard shortcuts have been changed in the GTK interface, since many of the old shortcuts interfered with typing (for example, binding the spacebar without modifiers to “pause”). Look around in the drop-down menus to find the new shortcuts."

In may case "some" means all the shortcuts I used before, like "f", "x", "c", "v", "r" etc. I tried out the new shortcuts, and I don't like them. I find it frustrating to be forced to use modifier keys, like CTRL + . for stopping playback. That's like suddenly forcing vim users to use emacs style shortcuts.

I don't even understand the reasoning. How does it interfere with typing? In most cases, why would I want to type anything in audacious except for searching?

I looked around in the settings in hope of finding a way to get the old shortcuts back. I found two plugins, "global hotkey" and "gnome shortcuts", but these are not what I want: it's not global, system-wide shortcuts I'm after, I need them only for audacious.

Is it possible to do somehow what I wish?

Replies (7)

RE: Configurable shortcuts in 3.2? - Added by Horst P. over 11 years ago


as mentioned in Bug #60 shortcuts without ctrl etc interfere with plugins, like the "search tool" for instance.
Personally, I also like different shortcuts, so I wrote myself a patch for audacious-plugins-3.2/src/gtkui/menus.c, see
It adds an identifier for each menu entry and reads for shortcuts in your local config file. If nothing is found there, the default shortcuts are used. Just add the shortcuts you want to change in the gtkui section, such as:


For the "ctrl" and "alt" key use mod=4 and 8, resp.

Feel free to use and modify!

RE: Configurable shortcuts in 3.2? - Added by anonymous password over 11 years ago

I've improved that patch; it now adheres more closely to the style of the surrounding code, shouldn't leak strings from g_strconcat, and parses GTK accelerator strings of the form <Control>w from the key_pause or similar settings, so it's easier to set the hotkeys and the method of doing so matches other programs that use GTK accelerator strings.

One further (but still missing) improvement would be to use a GtkAccelMap <> to allow users to change the shortcuts at runtime if they have the GTK setting "gtk-can-change-accels" enabled. This would necessitate adding the menu entries to the GtkAccelMap at creation and having a callback that would update the audacious configuration structure when shortcuts are changed.

RE: Configurable shortcuts in 3.2? - Added by karl anliot over 11 years ago

i am very unsettled by the change in keyboard shortcuts.

with the old version I could start,stop easily with the keyboard.
I don't even have this so called search plugin.

the only reason i liked audacious is because it was easy to use, and now you've gone and done this?

RE: Configurable shortcuts in 3.2? - Added by John Lindgren over 11 years ago

"Horst P." and "anonymous password", this patch is good progress. It would be great if someone could find the time to add the GtkAccelMap stuff. I'm not likely to have time to do it myself in the near future.

RE: Configurable shortcuts in 3.2? - Added by anonymous password over 11 years ago

This is a patch based on the previous ones that adds GtkAccelMap-based saving/loading of hotkeys and allows changing them at runtime with the gtk-change-accels GTK preference. It also fixes the issue of hotkeys interfering with text entry by checking whether a widget wants the keypress event for a given key combination and not handling the shortcut at the window level if one does. I'm not aware of any outstanding issues with this code, so I'm interested in seeing it or some variation thereupon getting committed if possible.

RE: Configurable shortcuts in 3.2? - Added by anonymous password over 11 years ago

Nuts, I generated that patch as a delta from bad originals; this patch is actually applicable for the 3.2 sources.

RE: Configurable shortcuts in 3.2? - Added by anonymous password over 11 years ago

And another tweak; this cleans up some other key handling so that ctrl+tab and ctrl+shift+tab work properly again; in general it changes window_keypress_cb to more directly return true if it actually handled a keypress.