Feisty’s Quod Libet ignores keyboard shortcuts

After changing my server to Xorg-air (from the package xserver-xorg-air-core from http://xgl.compiz.info/ the problem resolved itself, so I believe it’s a problem with Dapper’s X.Org, not QuodLibet. Reassigning.

Hmmm, after some more use the shortcuts are again not working. The only relevant change was to set System | Preferences | Keyboard | Layout Options | Compose key position to Caps Lock is Compose, but unsetting it doesn’t bring make the next/prev track shortcuts work.

Is there anything I can check to pinpoint the culprit of this issue?

After clean-installing Edgy (with X 1:7.1.1ubuntu6 and Quod Libet 0.23.1-1) I can’t reproduce this bug anymore.

This happens again in current Feisty (xserver-xorg 1:7.1.1ubuntu8, quodlibet 0.24-0ubuntu2), reopening.

where does quodlibet put those changes?

I have no idea whether it’s Quod Libet or X.org that’s broken here; X.org seems to get the keys properly (i.e., they show up in the keyboard shortcuts selector), so it either does not pass them to Quod Libet or Quod Libet doesn’t know what to do with them.

FWIW, the shortcuts work when Rhythmbox is open (and change the song in Rhythmbox).

confirming...

Traceback:

/usr/share/quodlibet/qltk/dbus_.py:11: DeprecationWarning: The
dbus_bindings module is deprecated and will go away soon.

dbus-python 0.80 provides only a partial emulation of the old
dbus_bindings, which was never meant to be public API.

Most uses of dbus_bindings are applications catching the exception
dbus.dbus_bindings.DBusException. You should use dbus.DBusException
instead (this is compatible with all dbus-python versions since 0.40.2).

If you need additional public API, please contact the maintainers via
<email address hidden>.

 from dbus.dbus_bindings import DBusException
Error grabbing key 172, 0x853bc00

Reassigning to quodlibet and marking as confirmed as per towolf’s comment.

Reassigning to Lukáš Lalinský as the quodlibet package bug contact.

Is there an easy fix for this that I could apply to a private build of the quodlibet package (I guess it’s too late to get it into Feisty…)?

I changed ‘from dbus.dbus_bindings import DBusException’ to ‘from dbus import DBusException’ in qltk/dbus_.py; unfortunately, this doesn’t fix this bug. :|

FWIW, Debian’s quodlibet’s 0.24-2 applies the http://sacredchao.net/quodlibet/changeset/4007 revision, which supposedly fixes this (as mentioned above, that change didn’t fix it for me, though).

That fix did not work for me either, is there a .deb for 0.24-2?

Why in the world are you guys looking at the D-Bus error to fix a multimedia key problem?

The reason it's not working is because something else is grabbing the key before we do. Hence the "Error grabbing key 172, 0x853bc00". You're probably running Rhythmbox or something else that wants to look at the multimedia keys at the same time as Quod Libet.

Joe,

I still get this problem no matter what programs are open. If I close them all and just keep Quod Libet open, my multimedia keys still don't work. It does not appear that another application is "intercepting" the key press event.

The point here is Quod Libet's media key functionality has been broken since the Feisty upgrade, and the Debian people saw the D-Bus problem as possibly causing the breakage.

If Quod Libet says "Error grabbing key 172, 0x853bc00" it means that something else is intercepting the key. Close all applications potentially using the multimedia keys, start Quod Libet at a terminal (*after* closing everything), then try. If you still see that message at a terminal, it means something - probably some GNOME core component - is still grabbing the key. If that's the case, this a "bug" in GNOME - I'm sure whoever made the actual change will claim it was a feature.

The Debian people did not see D-Bus as causing the breaking, towolf did. Thet Debian bug report was simply about Quod Libet using a deprecated D-Bus API and had nothing to do with multimedia keys.

I don't get the "Error grabbing key 172, 0x853bc00" in the terminal, but my multimedia keys still don't work. And yes, I had closed all other open programs *before* running Quod Libet from a terminal.

I second Rob D's comment, I also don't get the "Error grabbing key" message.

Furthermore, I confirmed the keys are "grab-able" with the following test:
1. Open quodlibet
2. Try using multimedia keys to control quodlibet -- no effect
3. Without closing quodlibet, open Rhythmbox
4. Try using multimedia keys to control Rhythmbox -- works fine

The full output of quodlibet when run from the terminal is as follows (up-to-date Ubuntu Feisty Fawn system:)

fraser@ged:~$ quodlibet
Supported formats: mod, mp3, mp4, mpc, trueaudio, wav, wavpack, xiph
Loaded song library.
Opening audio device.
/usr/share/quodlibet/qltk/dbus_.py:11: DeprecationWarning: The dbus_bindings module is deprecated and will go away soon.

dbus-python 0.80 provides only a partial emulation of the old
dbus_bindings, which was never meant to be public API.

Most uses of dbus_bindings are applications catching the exception
dbus.dbus_bindings.DBusException. You should use dbus.DBusException
instead (this is compatible with all dbus-python versions since 0.40.2).

If you need additional public API, please contact the maintainers via
<email address hidden>.

  from dbus.dbus_bindings import DBusException
Traceback (most recent call last):
  File "/usr/share/quodlibet/plugins/events.py", line 95, in _load
    try: obj = Kind()
  File "/usr/share/quodlibet/plugins/events/gajim_status.py", line 53, in __init__
    self.interface = dbus.Interface(dbus.SessionBus().get_object('org.gajim.dbus', '/org/gajim/dbus/RemoteObject'), 'org.gajim.dbus.RemoteInterface')
  File "/var/lib/python-support/python2.5/dbus/_dbus.py", line 410, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/var/lib/python-support/python2.5/dbus/proxies.py", line 230, in __init__
    _dbus_bindings.UInt32(0))
  File "/var/lib/python-support/python2.5/dbus/proxies.py", line 169, in __call__
    reply_message = self._connection.send_message_with_reply_and_block(message, timeout)
DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.gajim.dbus was not provided by any .service files
/usr/share/quodlibet/plugins/events/trayicon.py:15: DeprecationWarning: the module egg.trayicon is deprecated; equivalent functionality can now be found in pygtk 2.10
  import egg.trayicon as trayicon
Traceback (most recent call last):
  File "/usr/share/quodlibet/plugins/events.py", line 128, in __invoke
    try: handler(*args)
  File "/usr/share/quodlibet/plugins/events/autorating.py", line 20, in plugin_on_song_ended
    rating = song["~#rating"]
TypeError: 'NoneType' object is unsubscriptable

I just edited /usr/share/quodlibet/qltk/dbus_.py:11 as in the debian patch:

11c11
- from dbus.dbus_bindings import DBusException
---
+ from dbus import DBusException

This gets rid of the dbus_bindings deprecation warning when I start quodlibet from the command line, but it does not fix the multimedia keys problem. The other warnings seen in my quodlibet output above are still present.

Did you install quodlibet-ext?

Yes, quodlibet-ext is installed.

This *might* have something to do with different interface in new version of control-center included with feisty.
You might be interested in http://bugzilla.gnome.org/show_bug.cgi?id=395433 and also bug #32917 and bug #87299.

#87299 makes it look like GNOME changed their mmkey support to preempt any applications trying to do it themselves? Under bizarro GNOME logic I guess the way to make mmkeys work is to break them? Who knows. Supporting this new method involves buying into some new immature GNOME API, which Quod Libet won't do - it's not a GNOME application. It might be manageable as a plugin.

This isn't a problem in Quod Libet, it's a problem in GNOME.

I just went through Rhythmbox's changelog looking for clues and found this entry:

2007-02-02 Jonathan Matthew <email address hidden>

    * configure.ac:
    * data/rhythmbox.schemas:
    * plugins/Makefile.am:
    * plugins/mmkeys/Makefile.am:
    * plugins/mmkeys/mmkeys.rb-plugin.desktop.in:
    * plugins/mmkeys/rb-mmkeys-plugin.c: (rb_mmkeys_plugin_init),
    (media_player_key_pressed), (window_focus_cb), (grab_mmkey),
    (ungrab_mmkey), (filter_mmkeys), (mmkeys_grab), (impl_activate),
    (impl_deactivate), (rb_mmkeys_plugin_class_init):
    New plugin for media player key shortcuts. Handles both dbus signals
    from gnome-settings-daemon and the older XGrabKey method (bug #398184).

    * shell/rb-shell-player.c: (rb_shell_player_init):
    Remove XGrabKey key shortcut handling code.

The Gnome Bugzilla bug that this patch addresses has some more details in the comments:
    http://bugzilla.gnome.org/show_bug.cgi?id=398184

Attached is the diff of what I touched in quodlibet.py to get Multimedia keys working, :)

Now I have not only Play, as I had in Edgy, but also Next, Previous and Stop.

wow nice, big thanks. I already thought this would never be fixed.

As per Joe's suggestion this is probably better implemented as a plugin. I have written such plugin by adapting some existing code and Facundo Batista's patch. The plugin is attached. Simply save the dbusmmkey.py file in ~/.quodlibet/plugins/events/ and enable it in quod libet.

Ronny, I downloaded your plugin, and it works great! Thanks for your help with this.

One other person to confirm the bug with a fresh Feisty installation. Things worked fine on my Debian lenny a month ago. I'll try the above patch.

Patch is working, it is a viable solution to fix this issue.

Should be fixed with the following upload, available in Ubuntu gutsy:

quodlibet-plugins (20070529-1) unstable; urgency=low

  * New upstream svn snapshot.
    - New D-Bus multimedia key plugin.
  * Remove dh_python call in debian/rules since it doesn't do anything.

 -- Christine Spang <email address hidden> Tue, 29 May 2007 10:21:28 -0400

I'll close this bug, feel free to reopen if necessary.

the committed patch enables the multimedia keys in quodlibet except that after pausing a song you cannot get it to resume with another keypress (as it should: the button is play/pause, not just pause) I'll attach a one-line patch to fix.

diff to make play/pause button toggle
(I'm I patched against the right code, otherwise linenumbers might be off)

Eyal,

I'm using an up-to-date ubuntu gutsy with gnome and mapped the button called "Play (or play/pause)" to a button, and pressing the button pauses and resumes the player properly for me without your patch.

Your patch introduces no real different handling since the ^= operator works exactly the same as " = not" when working with boolean values.

You can check this by typing this into a terminal:

$ python
Python 2.5.1 (r251:54863, Aug 17 2007, 18:41:48)
[GCC 4.1.3 20070812 (prerelease) (Ubuntu 4.1.2-15ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> val1 = True
>>> val1 ^= True
>>> print val1
False
>>> val1 ^= True
>>> print val1
True
>>> val2 = True
>>> val2 = not val2
>>> print val2
False
>>> val2 = not val2
>>> print val2
True
>>>
----

Can you please check whether it really doesn't work without this patch and it does with it?

Sorry, my mistake.

I had an old copy of this plugin sitting in ~/.quodlibet (without toggle behaviour). I deleted that when changing things. I thought my one-liner fixed it, where the real fix was deleting the old plugin in ~/.quodlibet.

So, sorry for the confusion and please ignore my patch.

Okay, I'll set it back to Fix Released. Thanks for your contribution ;)