Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayfire 0.8

wayfire.org

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Wayfire 0.8

#51

Post by junon »

charcircuit wrote: post #35

>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.

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).

Re: Wayfire 0.8

#52

Post by junon »

nickstinemates wrote: post #36
charcircuit wrote: post #35

>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?

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.

Re: Wayfire 0.8

#53

Post by ammen99 »

rapnie wrote: post #45

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…

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.

Re: Wayfire 0.8

#54

Post by [deleted] »

resonious wrote: post #40
dizhn wrote: post #27

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.

[deleted]

Re: Wayfire 0.8

#56

Post by mananaysiempre »

jraph wrote: post #14
ammen99 wrote: post #8

Earlier quoted context omitted.

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…

> 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.)

Re: Wayfire 0.8

#57

Post by pxc »

dasyatidprime wrote: post #18
ammen99 wrote: post #8

Earlier quoted context omitted.

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?

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…

> 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?

Re: Wayfire 0.8

#58

Post by pxc »

dasyatidprime wrote: post #48
ammen99 wrote: post #13

Earlier quoted context omitted.

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-positio…

'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.

--

1: https://www.man7.org/linux/man-pages/man5/keymaps.5.html

Re: Wayfire 0.8

#59

Post by pxc »

Vinnl wrote: post #6
toastal wrote: post #4

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.

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. :)

Re: Wayfire 0.8

#60

Post by pxc »

binkHN wrote: post #30
OsrsNeedsf2P wrote: post #20

> 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 effec…

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.
Post reply on HN