[HN Gopher] Wayfire 0.8
___________________________________________________________________
Wayfire 0.8
Author : eirikurh
Score : 138 points
Date : 2023-10-10 09:57 UTC (13 hours ago)
(HTM) web link (wayfire.org)
(TXT) w3m dump (wayfire.org)
| ShadowBanThis01 wrote:
| Is?
| charcircuit wrote:
| >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.
| junon wrote:
| 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).
| nickstinemates wrote:
| Isn't dbus a pretty heavy dependency to bring in to a project?
| [deleted]
| vidarh wrote:
| 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.
| junon wrote:
| 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.
| charcircuit wrote:
| If a program is targeting the Linux desktop (freedesktop)
| then it should be assumed that dbus exists.
| ammen99 wrote:
| 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.
| OsrsNeedsf2P wrote:
| > 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
| binkHN wrote:
| Doesn't KDE's Activities handle this?
| pxc wrote:
| 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.
| OJFord wrote:
| > I've wanted this for 7 years
|
| Is there a good story behind how specific that is?
| onli wrote:
| What blocked you from using any other WM with multiple
| workspaces in such a configuration?
| jcelerier wrote:
| i've been using https://github.com/infokiller/i3-workspace-
| groups for this to great effect for quite some time
| bitdivision wrote:
| Thank you, this looks ideal. I've wanted a way to do this for
| a long time.
| tmtvl wrote:
| 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.
| [deleted]
| toastal wrote:
| 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.
| ammen99 wrote:
| 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?
| mato wrote:
| > 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 :-(
| tmtvl wrote:
| 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.
| codetrotter wrote:
| > 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.
| hnuser123456 wrote:
| 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"?
| ammen99 wrote:
| 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.
| dasyatidprime wrote:
| 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.
| pxc wrote:
| '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'.1 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
| dasyatidprime wrote:
| 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.
| malermeister wrote:
| > 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.
| ammen99 wrote:
| 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
| ..
| malermeister wrote:
| 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.
| jraph wrote:
| > 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.
| ammen99 wrote:
| 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...
| 05 wrote:
| 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..
| onli wrote:
| 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.
| woolion wrote:
| 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, Bepo, ...).
| ForkMeOnTinder wrote:
| 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.
|
| [1]: https://i3wm.org/docs/userguide.html#keybindings
| jraph wrote:
| 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.
| mananaysiempre wrote:
| > 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-Ch and Ctrl-s. 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.)
| skerit wrote:
| > 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.
| taeric wrote:
| 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.
| dasyatidprime wrote:
| 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?
| pxc wrote:
| > 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?
| dasyatidprime wrote:
| 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.
| Vinnl wrote:
| 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.
| pxc wrote:
| 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. :)
| notRobot wrote:
| 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.
| phkahler wrote:
| >> 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.
| solarkraft wrote:
| 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.
| dizhn wrote:
| 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.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...
| resonious wrote:
| > 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]
| [deleted]
| theorknfnfn wrote:
| Anyone using it daily? I'd love to hear about what makes the cool
| animations.. well, cool. My desktop is pretty boring right now.
| Congeec wrote:
| As an average user, wayfire has been pretty reliable since
| 0.7.5. It is just its ecosystem needs more work.
| tombh wrote:
| 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.
| bdhcuidbebe wrote:
| 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
| rapnie wrote:
| 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.
| stonogo wrote:
| 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?
| rapnie wrote:
| 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".
| pxc wrote:
| 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.
| ammen99 wrote:
| 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.
| olddustytrail wrote:
| 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.
___________________________________________________________________
(page generated 2023-10-10 23:02 UTC)