41–50 of 73 posts
>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.
Isn't dbus a pretty heavy dependency to bring in to a project?
>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.
Isn't dbus a pretty heavy dependency to bring in to a project?
Earlier quoted context omitted.
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...
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.…
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, ...).
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.
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…
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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 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.
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…
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?
One 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.…
> 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.