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

61–70 of 73 posts

Re: Wayfire 0.8

#61

Post by pxc »

rapnie wrote: post #49
stonogo wrote: post #46

Earlier quoted context omitted.

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.

Re: Wayfire 0.8

#62

Post by olddustytrail »

ammen99 wrote: post #53
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.

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.

Re: Wayfire 0.8

#63

Post by dasyatidprime »

pxc wrote: post #58
dasyatidprime wrote: post #48

Earlier quoted context omitted.

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

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.

Re: Wayfire 0.8

#64

Post by dasyatidprime »

pxc wrote: post #57
dasyatidprime wrote: post #18

Earlier quoted context omitted.

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?

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.

Re: Wayfire 0.8

#65

Post by bsder »

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.

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/

Re: Wayfire 0.8

#66

Post by charcircuit »

bsder wrote: post #65
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.

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.

Re: Wayfire 0.8

#67

Post by bsder »

charcircuit wrote: post #66
bsder wrote: post #65

Earlier quoted context omitted.

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.

Re: Wayfire 0.8

#68

Post by charcircuit »

bsder wrote: post #67
charcircuit wrote: post #66

Earlier quoted context omitted.

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

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

Re: Wayfire 0.8

#69

Post by jraph »

mananaysiempre wrote: post #56
jraph wrote: post #14

Earlier quoted context omitted.

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

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

Re: Wayfire 0.8

#70

Post by pxc »

dasyatidprime wrote: post #64
pxc wrote: post #57

Earlier quoted context omitted.

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

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

Post reply on HN