New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Quod Libet wants to inhibit shortcuts" #2644

Closed
relan opened this Issue Dec 2, 2017 · 9 comments

Comments

Projects
None yet
2 participants
@relan

relan commented Dec 2, 2017

Every time I click song duration button (next to volume button) to display progress, GNOME Shell displays this dialog:

quodlibet-inhibit-shortcuts

Regardless of whether I allow or deny, it appears again every time I click duration button. I expect no dialogs to pop up when I click it.

Quod Libet 3.9.1 (quodlibet-3.9.1-2.fc27.noarch from repositories)
Fedora 27
GNOME 3.26.2

@lazka

This comment has been minimized.

Member

lazka commented Dec 2, 2017

Hm, I've never seen this before. Do you use Wayland? (it should show either X11 or Wayland in QL>Help>About)

@lazka lazka added the bug label Dec 2, 2017

@relan

This comment has been minimized.

relan commented Dec 2, 2017

Do you use Wayland?

Yes. "About" says:

Audio device: GStreamer (autoaudiosink)
Python: 2.7.14
Mutagen: 1.38
GTK+: 3.22.26 (Wayland)
PyGObject: 3.26.1
GStreamer: 1.12.3.0

"Quod Libet wants to inhibit shortcuts" dialog does not pop up in X11 session.

@lazka

This comment has been minimized.

Member

lazka commented Dec 2, 2017

Thanks for testing. I'll ask gnome devs what this is about.

@relan

This comment has been minimized.

relan commented Dec 2, 2017

This looks like a regression because I've recently updated to Fedora 27. Never saw "wants to inhibit shortcuts" dialog in Fedora 26 with GNOME/Wayland session.

@lazka lazka added the wayland label Dec 2, 2017

@lazka

This comment has been minimized.

Member

lazka commented Jan 16, 2018

Just found https://bugzilla.gnome.org/show_bug.cgi?id=789268 for this.

The fix is in the gtk+ 3.22 branch and should be released with 3.22.27

@lazka

This comment has been minimized.

Member

lazka commented Jan 16, 2018

Uh, there is more behind this. The wayland backend in gtk was renamed, so our detection fails and this bug is a result of doing the popup sequence wrong.

But..... making it detect wayland again crashes gnome-shell. 😕

lazka added a commit that referenced this issue Jan 16, 2018

wayland: detect if wayland is running through the gtype name. See #2644
This is similar to what gtk+ is doing internally, so less likely to break.
Our current approach was broken as the display name format was changed
under wayland.

@lazka lazka added this to the 4.0.3 milestone Jan 16, 2018

@lazka

This comment has been minimized.

Member

lazka commented Jan 16, 2018

pushed to master only for now, until the gnome-shell issue is solved.

@lazka

This comment has been minimized.

Member

lazka commented Jan 17, 2018

@lazka

This comment has been minimized.

Member

lazka commented May 12, 2018

Seems to work again, using debian sid (3.28.x) and current master

@lazka lazka closed this May 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment