You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the hotkeys, it's whenever pyqtkeybinds decides to get around to implementing xdg-desktop-portal global keybind support (which I suspect will require a PR, given that it has "less than zero" support at the moment), but for external capture it's going to take a bit more work than just grabWindow(0) with a transparent window...
More specifically, Wayland requires applications to render to their own surfaces and any inter-window transparency is handled in the compositor; a grabWindow would only show transparent pixels. Well, that would be the case if QT actually bothered to implement grabWindow for wayland (which is actually a mostly unrelated issue, surprisingly). The "proper" way would be to grab the screen via dbus portal (ideally via a QT-provided abstraction layer, if one ever exists) and crop that to whatever dimensions the user selected with the overlay. There's also a bunch of stuff around "windows can't just draw over other windows willy-nilly", so the crop overlay will probably need some reworking as well to "request" to be put on top by that global keybind (I'm still not really sure how that works...)
This would require an absolutely insane amount of work that I currently don't have the time (or spoons) to help with, so I'm mostly just throwing this one out as a tracking issue that someone might want to get around to if they feel like learning how portals work (which also work on X11 linux as well, because they're not attached to the windowing protocol for stupid legacy reasons...)
The text was updated successfully, but these errors were encountered:
For the hotkeys, it's whenever
pyqtkeybinds
decides to get around to implementingxdg-desktop-portal
global keybind support (which I suspect will require a PR, given that it has "less than zero" support at the moment), but for external capture it's going to take a bit more work than justgrabWindow(0)
with a transparent window...More specifically, Wayland requires applications to render to their own surfaces and any inter-window transparency is handled in the compositor; a grabWindow would only show transparent pixels. Well, that would be the case if QT actually bothered to implement grabWindow for wayland (which is actually a mostly unrelated issue, surprisingly). The "proper" way would be to grab the screen via dbus portal (ideally via a QT-provided abstraction layer, if one ever exists) and crop that to whatever dimensions the user selected with the overlay. There's also a bunch of stuff around "windows can't just draw over other windows willy-nilly", so the crop overlay will probably need some reworking as well to "request" to be put on top by that global keybind (I'm still not really sure how that works...)
This would require an absolutely insane amount of work that I currently don't have the time (or spoons) to help with, so I'm mostly just throwing this one out as a tracking issue that someone might want to get around to if they feel like learning how portals work (which also work on X11 linux as well, because they're not attached to the windowing protocol for stupid legacy reasons...)
The text was updated successfully, but these errors were encountered: