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

Linux Wayland Support - Understanding Changes Needed #14

Open
seltzered opened this issue Aug 1, 2021 · 4 comments
Open

Linux Wayland Support - Understanding Changes Needed #14

seltzered opened this issue Aug 1, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@seltzered
Copy link

seltzered commented Aug 1, 2021

Hi, just starting to look at the code and wondering what would be needed for wayland support. If it's just around the hotkey triggering limitations I know some projects (e.g. kupfer) have just worked around needing X11KeyManager by having a command-line method of invocation paired with instructions to setup a custom shortcut (e.g. via gnome settings).

Opening an issue to discuss/understand if there's other aspects to be considered in attempting to support wayland.
(Thanks for your earlier advice, application works fine under x11)

@danpla
Copy link
Owner

danpla commented Aug 4, 2021

Hi.

Wayland support requires writing a separate backend, which will handle:

  • Global hotkeys. Wayland doesn't support them by design. Indeed, a workaround is to provide a form of IPC, so that users can bind a command like dpscreenocr toggle-selection in the system hotkey manager.

  • Drawing the selection rectangle and resizing it with the mouse.

  • Screenshots. Wayland doesn't support this as well. This is probably the most problematic part, since each major desktop provides its own DBus interface for taking screenshots. For example, both Flameshot and GIMP handle 3 different cases for GNOME, KDE, and org.freedesktop.portal.Screenshot. In general, the amount of Wayland-related bugs in Flameshot makes me think that Wayland support (at least at the current state of Wayland) will be painful.

If someone has enthusiasm for writing and supporting a Wayland backend, I'll be glad to help. But I'm not currently interested in doing this myself, since I'm not going to switch to Wayland in the near future.

@danpla danpla added the enhancement New feature or request label Apr 18, 2022
@lamyergeier
Copy link

@danpla I was wondering is it still possible after 2.5 years since your previous message. Also, most linux distributions have moved to wayland, please check if its possible.

@seltzered
Copy link
Author

seltzered commented Dec 31, 2023

@lamyergeier worth noting there's some other tools that work on wayland (see https://github.com/dynobo/normcap#similar-open-source-tools ), I've been using frog ( https://github.com/TenderOwl/Frog ) and normcap ( https://github.com/dynobo/normcap )

@Kirinko
Copy link

Kirinko commented Mar 7, 2024

@danpla Hi there! Today my KDE updated to 6.0 with Wayland as default and obviously dpscreenocr stopped working. Such a pity there is no symmetrical alternative to it in Wayland (I mean calling with a hotkey a capture grid wherever I want on the window. Both Frog and normcap have to capture whole display first and only then gives you an ability to limit the ocr region). Please, consider providing Wayland support for your fantastic app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants