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

"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

Comments

@relan
Copy link

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

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

@lazka lazka commented Dec 2, 2017

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

@relan
Copy link
Author

@relan 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 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 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
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 lazka commented Jan 16, 2018

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

@lazka
Copy link
Member

@lazka lazka commented Jan 17, 2018

@lazka
Copy link
Member

@lazka 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants