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

X11 #789

Open
hexplor opened this issue Mar 1, 2023 · 1 comment
Open

X11 #789

hexplor opened this issue Mar 1, 2023 · 1 comment
Assignees
Labels
question Further information is requested

Comments

@hexplor
Copy link

hexplor commented Mar 1, 2023

First of all, truly amazing, extraordinary and useful work. Thank you. Short question. Any chance for using that in Wayland (Ubuntu). Right now, I'm switching to X11 on login but Wayland is much snappier on Ubuntu. Thanks for your work.

@hexplor hexplor added the question Further information is requested label Mar 1, 2023
@RedBearAK
Copy link
Contributor

@hexplor

I can say that there is a very good chance Kinto can work with Wayland, because I was able to make a completely working branch of keyszer that functions in Wayland, and allowed me to use a Kinto config. But there are many caveats with what I came up with. Lots of extra dependencies.

The situation in Wayland is much different from X11. The solution I came up with only works in GNOME (so far), and only after you install one of two known GNOME Shell extensions (Xremap or "Window Calls Extended") that help get the window attributes to enable the app-specific keymaps. The extensions are required to get the window class and title/name attributes, then a new module in keyszer can talk to the extensions via D-Bus. There is no way that I could find to get this information directly from the Wayland display server.

The keyszer branch for Wayland that I made is technically working, but it's a big mess and will never be part of keyszer in its current form. There needs to be a more generic architecture to allow keyszer to be told to use a specific "provider" of the window attributes, rather than just being tied directly to the module that gets the X11 window attributes. It will take some extensive work.

All that I've shown with the proof of concept branch is that it will be possible to support Wayland+GNOME+extensions, and maybe Wayland+sway at some point. It should also theoretically be possible to pull the same kind of information using a KWin script in KDE Plasma, but I know very little about how to do that. Outside of those limitations, Wayland itself will have to gain the ability to provide access to the relevant window attributes. There is a chance that wlroots will have something to do with this, and maybe this will all be much easier in the future.

Anyone who is good with Python, and might know how to turn the existing xorg module into a more generic class that can be extended more easily to other types of window attribute providers, might want to take a look at what the branch is doing.

joshgoebel/keyszer#136

If you want to actually attempt to use the branch, you'll need a Kinto config designed to work with keyszer, like the ones posted here:

#750

And you'll need the ability to get through installing all the native packages and pip packages that make it work. That will vary significantly depending on which distro you're using.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants