Live data from Hacker News

Wayland in 2021

shibumi.dev

141–146 of 146 posts

Re: Wayland in 2021

#141
post #79

Earlier quoted context omitted.

I assume it starts with showing you’re up to it by putting in the work. You don’t need to be the release manager to contribute patches.

But who will review your patches, if all the core devs have already moved on to Wayland?

It's open source, you can provide your own distribution of it.

Re: Wayland in 2021

#142
post #33

Earlier quoted context omitted.

I'm using https://github.com/greshake/i3status-rust which also works well with Sway.

I currently use i3status-rust. with a lot of custom blocks, with X. I'm thinking of switching to Sway. Did you have any config problems?

Not that I can think of, but obviously it depends on what your blocks are doing. I remember having trouble with the backlight block, but I fixed that upstream a long time ago, so it should not be a problem for you anymore.

For reference, my config is at: https://github.com/majewsky/devenv/tree/master/i3status-rust (as a bunch of single-purpose snippets, the actual config file is obtained by concatenating `common/.toml` and `$HOSTNAME/.toml`)

Re: Wayland in 2021

#144
post #106

Earlier quoted context omitted.

> A unified way to change applications settings. This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings > because the X server takes care of most of the stuff. ... , unless using a big library like wl_roots. So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? > A base graphics API based on drawing primitives like th…

> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? There is big difference in responsibility w.r.t. users in Xserver vs wl_roots case. In the X11 case, relations are: wm - user - X11 (Users choose to use Xserver and WM independently, if there is a bug in Xserver, then it is outside of responsibility of WM developers.) In the Wayland case, the relations are:…

That's actually a good thing! If the bug is in X, then the WM developers are powerless against it. If it is in wlroots, then something can be done about it. Since it's a library, it should be possible to roll out a bugfix at a faster pace than the X server. Worst case you fork and bundle wlroots, leave behind a pull request to the main project, and move on.

Re: Wayland in 2021

#145
post #132

Earlier quoted context omitted.

> This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings That's why I said Wayland and the modern desktop in general. > So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X s…

> which makes the protocol use a lot of bandwidth. not true in most of the use cases. ownership of bitmaps are transfered, no actual pixels are being copied.

Sure, locally: I had a remote display in mind.
Post reply on HN