Wayfire 0.8
wayfire.orgOne of the developers just responded on the github issue referecing this thread. (Also reopened the issue and removed wontfix)
"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 actual 'issue' here is that they expect the key binding changes together with the layout.
The issue is that people expect "KEY_Q" to refer to the key that inputs a "q", no? Classic desktop-Linux-level user friendliness.
I gave Wayfire a shot a bit earlier in the year, but as I am a Dvorak typist and <https://github.com/WayfireWM/wayfire/issues/1601> is marked as "wontfix", I decided to stick to Awesome for the time being. It did run like a dream, though, even on my ancient potato, so if the keybinding issue does get fixed at some point I may well switch over.
Oof. That is not an acceptable way to treat the issue. It’s one thing to say you don’t the time & cycles, but it’s another to WONTFIX it twice with a clear usability problem.
As the maintainer of Wayfire, I would like to say why I don't consider this a critical issue: the current system allows you to bind actions to a particular physical key. So, no matter what physical keyboard layout and actual layout in software, with the current system, you can bind the action to the desired physical key. Or do people actually want their keybindings to change when they change their layouts?
> Or do people actually want their keybindings to change when they change their layouts?
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.
I am mostly trying to understand what people actually use. I hate exactly this thing in most applications: ctrl-z doesn't work when I use the german layout (usually I use qwerty/us), and assumed most people would dislike it as well...
I personally like the flexibility of i3's keybinding config.[1] For each binding it lets you choose either:
- a keysym (the letter Z, wherever it happens to be in your current layout)
- or a keycode/scancode (the physical button under your pinky, no matter the current layout)
I use both methods for different bindings. For example I've bound the vim keys (hjkl) by scancode, and the layout keys ("S"tack, "F"ullscreen, "R"esize, etc) by symbol.
If someone ever does a survey, I'd be interested to read a blog post on this :-)
In my case I'm not sure what I prefer. When switching from AZERTY to QWERTY, I'm lost because the keybindings are not the same. Especially that CTRL+Z "becomes" CTRL+W which kills the current tab, and CTRL+W "becomes" CTRL+Q which kills the app.
OTOH, I don't usually switch layouts, and like that the configuration file / the UI matches the current layout.
I guess the conf could allow setting layout-specific keybindings. It complicates things quite a bit though.
But that's easy. All software does something like CTRL-Z accordingly to the chosen layout. So the physical position of the switch to press on the keyboard changes accordingly to the layout, it changes when switching from qwerty to qwertz and again when it switches to dvorak.
I saw a few games where it wasn't that way, it was always treated as a bug.
Think of it from the user side: People are used to their shortcuts. They are used to press CTRL+Z where it is on their layout, as their keyboard keys will also be printed accordingly. Someone with a non-qwerty-layout may have never seen CTRL+Z leading to the physical key on the bottom left, for them it was always somewhere else. How would they know what to press, when the config says CTRL+Z, and they press CTRL+Z on their keyboard and nothing happens? How would someone who grew up with azerty know qwerty?
If you want to support "what people actually use", the keypresses have to be evaluated according to the actual keyboard layout used. I say this with absolute certainty, and as a multilingual developer who switched from qwertz to qwerty and had azerty in use as well for a time.
To be fair, the example of a game is a pretty poor one: it's the main case where the key positions are more important than their code --WASD->ZQSD in AZERTY for example; if the game still maps WASD, it's just unusable as direction input. The "press W" and nothing happens is annoying, but in that case it's the lesser of two evils. And the only good answer in that case is that you need to rebind your keys.
Of course the best is the ability to remap and to adapt such positional keybindings to (known) layouts. But it's a big 'localization' task to consider all niche layouts (Dvorak, Colemak, Azerty, Bépo, ...).
One more thing to think about: some layouts don't have Latin letters. So if you switch from English to Ukrainian, you'd lose all your keybindings with the approach requested in the ticket..
> That's what actually happens everywhere.
That’s emphatically not what happens everywhere. It might be what happens everywhere people use a single Latin layout, but if you use two layouts or more you definitely want things to stay on the same physical key regardless of any switching—your muscle memory is bound to hate you otherwise.
For example, I expect CUA cut to be Ctrl-X, but also Ctrl-Ч and Ctrl-ס. This is how it works on all graphical desktops I’ve used and also, with some work, in Vim. (Not in Kakoune, though, which is a substantial annoyance.)
> your muscle memory is bound to hate you otherwise.
Yes, exactly what happens when I switch from AZERTY to QWERTY. Everything is messed up.
Now my use of everywhere was abusive, I guess not everywhere. It can't be Z if Z is not on your keyboard.
As another non-QWERTY user, I usually want desktop keybindings (excluding games) to follow layout changes, because I'm remembering the function by the mnemonic. Most applications have this behavior on my existing FDO/Linux system. On the Windows machine I use sometimes, by contrast, it seems like holding Control effectively forces QWERTY, which has been an unending source of little pains. If I didn't already have the QWERTY keymap memorized and I had to figure out which keys were “actually” which to configure things, it would be a lot harder.
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?
> because I'm remembering the function by the mnemonic.
Perhaps this is also a frequency of use issue— if you're relying on the mnemonic rather than muscle memory, it sounds like a shortcut you don't use very often.
Or does muscle memory for you come in at a different layer somehow, where the mapping to key locations is basically automatic and instant but you do still consider key names as you navigate hotkeys?
The latter and definitely not the former, in my case. As far as I can tell from internal experience, my automatic procedural memory of where to reach for a character, function, or string transforms along with the layout I currently have it “configured” to use, in a rough mirror of how scancode↔keysym mapping can vary on the OS side. I have used a non-QWERTY layout full time for about 18 months now after being in mostly-QWERTY before, so my QWERTY memory has decayed somewhat, but I have past experience switching back and forth at a time scale of hours. If I want the eyedropper tool in GIMP, I reach for the O, and there isn't a separate conscious step of “okay, so that's O, right?”, it's just a single compound action. If it has to be the O in some other layout than the one I'm using, then I have to stop myself and consciously try to remember where it would be. The tools that I don't use as much I do also have to stop and remember, but that's very distinct in feel.
I wonder sometimes whether it's relevant that I'm a heavy Emacs user, in which short command gestures often include non-modified keys and are conceptually close to the physically more text-based M-x invocations. Maybe that type of experience (or what other types? Maybe CLI?) creates a different mental map of the distinction or lack thereof between text entry and shortcut keymaps. Emacs on Windows is especially awkward for me as a result of the QWERTY-on-Control behavior, because e.g. C-x C-t and C-x t now involve different positions for the T. Or maybe people who start out on non-QWERTY layouts on Windows specifically are pushed to remember shortcuts by their location early because the keysyms are illogical, and then they continue doing that, but people who stay on QWERTY all the time could go either way?
As others have mentioned, this also doesn't happen as much in gaming, where commands are often bound positionally, with WASD motion (GAST motion in my layout…) as a central example. There's still some expected-keysym mnemonic influence in which of multiple candidate keys to bind to a function as one moves away from the central motion cluster. The vi keys mentioned elsewhere are also very positional in nature, but I rarely use vi bindings, and when I do, the nav-cluster keys are usually an accepted alternative…
Gosh. With how much has wound up in this thread, I kind of wonder whether there's more serious ergonomics research on this difference in mental modeling now.
> Emacs on Windows is especially awkward for me as a result of the QWERTY-on-Control behavior, because e.g. C-x C-t and C-x t now involve different positions for the T.
Okay, now that sounds absolutely maddening, mixing layouts in a single sequence like that.
The way of working you describe makes sense to me. I think you might be on to something with the bare letter keys used in Emacs combinations priming users to think one way and the positional, WASD-like nature of vi bindings pointing users another way (when it comes to basic cursor navigation). I use Emacs as well, with a mix of Evil and traditional bindings...
For now I'm glad that I'm just using one keyboard layout! Hehehe.
> do people actually want their keybindings to change when they change their layouts?
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.
People's brains just work differently. I don't remember "closing Awesome is Mod4 + Shift + the second key from the left on the bottom row", I remember "Mod4 + Shift + Q (for 'quit')" and my fingers know how to find 'Q'. If I change to Qwerty I'd have plenty of applications where the locations of keyboard shortcuts would change (like "Ctrl + C (for 'Copy')") and not having the keyboard shortcut for "close Awesome" change would be disorienting.
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.
> do people actually want their keybindings to change when they change their layouts?
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.
Wait, so you use both colemak and the normal qwerty layout and switch between them on the same keyboard?
As a vim user, I am hugely relying on muscle memory - which is why saying that bindings should vary between layouts seems really weird, as that would make muscle memory way less effective. Then again, that is my usage ..
It's kind of hard to explain, but I think my brain doesn't go "letter -> key on keyboard", it goes "letter -> location in keyboard layout -> key on keyboard".
If the key on keyboard stays the same, even though the layout changes, it really messes with the way my brain maps from letters to muscle movements, idk if this makes sense.
> Or do people actually want their keybindings to change when they change their layouts?
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 :-(
I definitely think of keys per my layout, not what is on the cap. I'd expect that to be the norm for touch typists.
I edit in Vim using Dvorak. I always expect `ciw` to “change inner word” regardless of layout. Most shortcuts are stored in my head in this way, not by physical key placement. That said, it doesn’t bother me that xmonad sets up my keys based on the default layout, so if I switch to another to type in a non-Latin script, the WMs shortcuts stay bound to my ‘normal’ keymap as the others are only used temporarily.
> the current system allows you to bind actions to a particular physical key
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.
Presumably, if one replaced their physical keyboard with one with a different layout, then change the layout to match in software, then the binding would still apply to the same "physical key location"?
Bindings respond to a particular hardware key code. If you have a qwerty keyboard, when you press the key labeled as 'Q', the keyboard sends a `KEY_Q`. If you take a different physical device, `KEY_Q` will probably be reported for the key where `Q` is written on the new keyboard.
This is contrary to my understanding of mainstream keyboard technology. Scancodes, like what you're looking at with Linux input, mainly refer to physical positions relative to a “standard” keyboard, and the labels in the header file for the alphabetic section are based on assuming the keyboard is QWERTY. A keyboard that comes from the manufacturer with different-layout keycaps on it will still output physical-position-based scancodes, and KEY_Q in the header file is not normally generated by the key that the manufacturer shipped a cap labeled Q on; it's the key in the position that would output Q if it were a QWERTY keyboard. (Though there's a few edge cases around e.g. ANSI vs ISO layout.)
This idea is corroborated if you look in the USB HID Usage Tables that the Linux input event codes are based on. From https://usb.org/document-library/hid-usage-tables-14:
> Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate other languages.
This can get somewhat more complicated when you get into keyboards with custom remapping firmware where they do actually shift the scancodes around, but that creates other potential issues, and users who are doing that basically just have to deal with their own integration tradeoffs. Similar considerations apply to keyboards with non-mainstream physical layouts.
'Q' isn't a scancode, though. The scancode is some weird number. 'Q' is a symbol, what the Linux keyboard tools project calls a 'keysym'.¹ The displeased users are expecting the symbolic-looking name to behave like a keysym in xmodmap or various WMs, and thus to be mapped according to layout. But in Wayfire, it's a short name for a scancode based on the mapping for QWERTY.
Imo it makes sense to support defining mappings according to both modes of reference, and even allow mixing them into a single config. Neither way of thinking seems inherently better or worse to me. Just depends on preference, intuition, and expectations.
--
That's the same thing I was getting at, yes. When I said “KEY_Q in the header file”, I was referring to the #define that attaches it to a number (edit to clarify: in linux/input-event-codes.h, specifically, which seems most likely to be the source of calling these KEY_* in the context of a Wayland compositor) and pointing out how it doesn't actually map to the conceptual Q, and that's why I mentioned scancodes specifically. Keysyms are indeed a separate layer, and I agree that users expecting to be able to configure on keysyms and being given the QWERTY-derived scancode mapping instead is confusing.
It seems fine to me. They don't want to update it, so they close the issue. They're under no obligation (not even a moral one) to change their plans, and everyone's free to fork it to implement their own plans.
They seem interested in user feedback and genuinely curious about the use cases of others, though, as evinced by their activity here.
Seems like a great time to politely make a case for one's preference, given the new attention and interest. :)
Even better :) Either way nothing to be mad at them about.
Since the last comment in that thread says there might be some progress at the time of the 0.8.0 announcement, it might be worth asking for an update.
>> It did run like a dream, though, even on my ancient potato
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.
> The purpose of workspace sets is to have a dedicated set of normal workspaces for different activities the user does on their computer. For example, I have one workspace set (containing a 2x2 workspace grid) dedicated to Wayfire, where I have Wayfire’s source code, GitHub issues, wlroots, etc. There is another workspace set dedicated to a project I am working on for university, and so on. Of course, a similar effect could be achieved with a single bigger workspace grid, but having a 5x5 workspace grid quickly becomes difficult to navigate.
I've wanted this for 7 years
i've been using https://github.com/infokiller/i3-workspace-groups for this to great effect for quite some time
Thank you, this looks ideal. I've wanted a way to do this for a long time.
Doesn't KDE's Activities handle this?
I think they also want tiling behaviors, but I think you can get at least starting positions of application windows in activities and virtual desktops via KWin rules.
What blocked you from using any other WM with multiple workspaces in such a configuration?
> I've wanted this for 7 years
Is there a good story behind how specific that is?
I used Wayfire for a while a couple of years ago. When I checked it out again a few months ago it seemed fairly unmaintained.
I'm happy it's alive because I find it to be a great and hugely underrated compositor with great potential.
Tangential. This is a cool project. But I notice how many projects similar to this one make it hard to find that out. The landing page says:
> 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.
Opportunity for what? This isn't a sales environment, and I'm not sure what the benefit is of attracting users who don't know the tools they use. What is the opportunity cost of losing a user who doesn't understand the benefits of the project?
Nothing sales related. I am a FOSS contributor checking HN regularly and may think "Oh, what's this?" but not spend 2min. in that session. A simple different text could avoid me losing interest. Unless the goal is "If you don't already know about wayland (compositors) this project isn't for you".
Most F/OSS projects probably don't want users who will ignore all but highly productized presentations of their work. That's almost certainly a counter-signal of a user's likelihood to file useful bug reports, let alone contribute.
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.
What wording would you use? I honestly have no idea how to describe Wayfire in other terms that would be more understandable to the majority of people.
Maybe rather than saying what it is straight away, say what it does and why you'd want it. "Wayfire: awesome visual effects for your Linux desktop" and then go on to say what it is.
You might even have a short bullet list of reasons to use it rather than just a tagline.
>IPC socket
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.
In what way is DBus better than something like Cap'n Proto? What does it cover and not cover? What other IPC/RPCs compete with 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 what way is DBus better than something like Cap'n Proto?
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.
> 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.
>People don't seem to use DBus at all outside of Linux.
Because it is a part of freedesktop, a project largely about creating software and specifications for the Linux desktop. Windows has COM. Mac / iOS have XPC. Android has Binder.
> 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.
It is from cultural and educational issues. It isn't just a coincidence that all operating systems I listed above have a standard IPC mechanism that they use for services.
DBus is a great protocol. It's also a very slow protocol. It's also very cumbersome to implement. The official libraries are quite messy and very opaque. It also assumes you're using systemd, which isn't always the case (I love systemd personally, but there are valid reasons, even non-technical ones, for people to choose not to use it).
The IPC plugin is optional (you don't have to enable it) and nothing stops you from writing a dbus plugin to accomplish the same tasks :)
Personally, I prefer IPC because it is simpler to implement, debug and use.
Isn't dbus a pretty heavy dependency to bring in to a project?
Dbus can work peer to peer and the protocol is lightweight, so using the protocol and giving the option of either binding to a socket or connecting to the message bus isn't that much effort, and then you cater for both people who want to run the message bus and those who don't.
If a program is targeting the Linux desktop (freedesktop) then it should be assumed that dbus exists.
Not really. It's just a bit cumbersome to use and assumes a lot about the system's setup. The protocol itself is actually pretty lightweight and simple. The library is a pain to deal with at times, at least it was several years ago.
Anyone using it daily? I'd love to hear about what makes the cool animations.. well, cool. My desktop is pretty boring right now.
I've used Wayfire everyday for a few years now. Although I'm into customisation and tinkering, (so things like Arch, Neovim, and indeed Wayfire, are to my taste), I don't like tiling window managers. I find it's like turning my living room into a workshop. A living space should have sunlight, plants and a sofa to welcome friends. In my opinion wobbly windows and other silly animations are nearer to that kind of organic aesthetic.
Wayfire is a living space I can tinker with.
I rather have a boring and stable desktop than these trend of the week WM:s. Time will tell if they even stick around, and become a reasonable daily driver.
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
As an average user, wayfire has been pretty reliable since 0.7.5. It is just its ecosystem needs more work.
Is?
<crickets>