"After a bit of discussion on HackerNews, I got a bit better understanding of the actual problem. People don't want to just configure the keys according to a particular layout - the actual 'issue' here is that they expect the key binding changes together with the layout. Unfortunately, the 0.8.0 changes didn't make this possible to implement as a plugin.
I would reconsider adding this as an option if there are enough interested people. React with a thumbs up to this comment if you are interested in having this option (though the defaults will certainly remain as they are now). Please, react only if you actually use Wayfire or would use it if it had this feature :)"
https://github.com/WayfireWM/wayfire/issues/1601#issuecommen...
The issue is that people expect "KEY_Q" to refer to the key that inputs a "q", no? Classic desktop-Linux-level user friendliness.
That's what actually happens everywhere. For instance undo is usually CTRL+Z. On QWERTY that will be CTRL + the key at the left side of the X, and on AZERTY that will be CTRL+the key at the left side of the E. Therefore, that's the behavior people expect and it has advantages. Having to write KEY_Z to actually have KEY_W is also jarring and very counter-intuitive. That also means UIs don't have to translate key bindings, unless they want them to correspond to some word (for instance word processors have CTRL+B for bold in English, but CTRL+G is allowed in French (Bold = Gras).
Now I also understand the benefits of your choice, and I appreciate that nobody is entitled to make you change this in any case. At worse everybody should be thankful for your choice to release this work as open source and spend time on it to the benefit of everyone. I'm also not a user so I don't have any stake in this.
But then, I'm an X user still; I'd like to dip into Wayland, but a combination of fragmentation of protocols and the seeming relative “hardness” of the stack in terms of customizability have caused me to hesitate thus far. And maybe that Windows behavior also means that's what you want to mimic for a lot of other people?
Personally, yes. If I am in Qwerty and I press the T key, I press the button where T is physically in Qwerty. If I am in Dvorak, I press the button where T is physically in Dvorak. Pressing the button where something is physically in Qwerty when I am in another layout would be very confusing, because effectively it would be that everything else is respecting the layout I am using except this one program that is still using the Qwerty positions of the keys.
That said, maybe I'd have an easier time if it were possible to find a physical Dvorak keyboard, but alas: "worse is better".
OT: Wayfire is a really cool project and I admire how well it runs, it's real quality software.
As a colemak user, definitely. It's a super weird and confusing experience otherwise and this bug is a blocker for me checking out your (otherwise quite promising-looking) project.
It depends. As a counterpoint to the folks replying "yes", I have for years had Meta-[1..9] bound to "switch to desktop X". I also regularly use US English and Czech/Slovak keyboards.
In the X11 days, I never had to think about this, since for whatever reason (I believe technically a bug and/or X11-specific WM behaviour, but I've lost the reference...) Openbox would use the US English layout for its keybindings exclusively.
Since I switched to KDE Plasma on Wayland, I constantly get annoyed, every day, as I may have my keyboard set to SK, press what muscle memory says is Meta-[1] and instead I get a funky zoom, since that keystroke translates to Meta-[+] in the SK layout :-(
A particular physical key... on a QWERTY keyboard. But we don't have QWERTY keyboards, so having to bind something to KEY_Q when you want it to map to an A is stupid.
Seems like a great time to politely make a case for one's preference, given the new attention and interest. :)
I believe this is the compositor they're going to run on Raspberry Pi 4 and 5 with the next OS release, so it makes sense it will run on more limited hardware.
I've wanted this for 7 years
Is there a good story behind how specific that is?
I'm happy it's alive because I find it to be a great and hugely underrated compositor with great potential.
> Wayfire is a wayland compositor based on wlroots. It aims to create a customizable, extendable and lightweight environment without sacrificing its appearance.
Now a visitor should know what "wayland" is, and then what a "wayland compositor" is, and only then can they decide if the project is interesting. The description assumes this knowledge, but many people will not take the time to figure it out and just surf to the next interesting thing. Opportunity missed.
But regarding this project in particular, you have lots of clues. There's a screenshot right there on the page. 'WM', short for 'window manager' is right there in the GitHub organization name. 'Compositor' is a standard term in this domain. It links to the most famous ever compositing window manager on its platform as a source of inspiration.
There are basically two groups of people that actively choose a specific window management stack instead of just choosing a whole operating system: advanced or growing Linux hobbyists, and the makers of Linux distros. Both of those groups will absolutely know what Wayland is, and will be able to tell what Wayfire is. And being a member of either requires more than the scant patience you've indicated you have for projects like this.
If you don't know what Wayland is and you're committed to not learning it instead of taking '2 minutes' to look it up, you're not the type to choose a window manager or configure a bespoke desktop environment.
You might even have a short bullet list of reasons to use it rather than just a tagline.
This IPC is a custom built IPC that has no security. This means that any program can do stuff like steal focus or drive other window manager policy if the plugin is there. There is also a plugin that exposes the ability to send key or mouse events.
Applications should just use DBus instead of creating their own custom IPC protocols just because they feel like it.
When I start seeing C++, AUTH, and Kerberos I start getting concerned.
When I don't find a Python-only module for something claimed to be "simple", I start getting very concerned: https://pypi.org/project/dbus-python/
In this specific context it is less about being better and more about being the standard for apps that are part of the Linux desktop except for Wayland which has its own. There are benefits in developers all being familiar with dbus, not having to use different clients for each program you want to talk to, it is easier to secure, etc.
Is it those things?
People don't seem to use DBus at all outside of Linux. That would seem to imply that, by and large, it isn't those things. And the fact that someone on Linux in exactly the situation where it should be used wasn't willing to use it suggests that maybe there are significant issues.
Personally, I prefer IPC because it is simpler to implement, debug and use.
Wayfire is a living space I can tinker with.
In wayland-land the only one I managed to use for a couple of days without crashing was sway in 2022. Both their last release and sway-git is crashy
