Skip to content
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

Jump to bottom

"Quod Libet wants to inhibit shortcuts" #2644

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

"Quod Libet wants to inhibit shortcuts" #2644

relan opened this issue Dec 2, 2017 · 9 comments
Labels
bug forwarded-upstream wayland
Milestone
4.1.0

Comments

@relan
Copy link

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
Copy link
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
Copy link
Author

relan commented Dec 2, 2017 •
edited

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
Copy link
Member

lazka commented Dec 2, 2017

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

@relan
Copy link
Author

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
Copy link
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
Copy link
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
@lazka
wayland: detect if wayland is running through the gtype name. See #2644
9ae9653 
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
Copy link
Member

lazka commented Jan 16, 2018

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

lazka referenced this issue Jan 16, 2018
@lazka
albumlist: make it search the right tags again. See #2723
3ff1c68
@lazka
Copy link
Member

lazka commented Jan 17, 2018

Filed a bug with mutter: https://bugzilla.gnome.org/show_bug.cgi?id=792599

@lazka
Copy link
Member

lazka commented May 12, 2018

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

@lazka lazka closed this as completed May 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug forwarded-upstream wayland
Projects
None yet
Milestone
4.1.0
Development

No branches or pull requests
2 participants
@lazka @relan