Re: [dev] Wayland compositors

[Teodoro Santoni]

2021-09-17 13:54 GMT+02:00, Страхиња Радић :
> Exactly what Wayland's monolithic,
> opinionated concept doesn't. If a compositor crashes, the whole session
> goes
> down.

Wayland isn't monolithic, BUT is a faulty funnel. It does one thing,
does it poorly, and cuts some well-established use cases in the
process.

> It doesn't matter who is responsible. If Wayland is not finished, its
> developers
> shouldn't act like it is and force it on users and programmers.

That's to me the most insane part of RedHatWare (systemd, wayland,
pulseaudio, GNOME, dbus, udev, polkit, consolekit): it's shipped
unfinished and buggy but the universe is now required to replace old,
clunky apparatus with new, shiny, miscarriaged foetus.

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/16, 20:36, Kyryl Melekhin wrote:
>And remember, always follow unix philosophy - go for what works first, optimize
>it later.

This should read "programs should do one thing and do it well" (DOTADIW)[1],
with the added "and work together".  Exactly what Wayland's monolithic,
opinionated concept doesn't. If a compositor crashes, the whole session goes
down. Comparatively in X.Org, you lose window transparency, shadows and
animations and can continue your work as normal. Wayland is in many ways
reminiscent of systemd.

[1]: https://en.wikipedia.org/wiki/Unix_philosophy


On 21/09/17 06:33, Tobias Bengfort wrote:
>I think much of the hate for wayland is misdirected. 

Although I cannot speak for everyone, criticism of Wayland is driven by facts,
not emotions. "Hate" or "love" don't have anything to do with it.

> Don't get me wrong, the state of wayland is bad. But IMHO that is not entirely
> the wayland people's fault.

It doesn't matter who is responsible. If Wayland is not finished, its developers
shouldn't act like it is and force it on users and programmers. Ideally, common
courtesy would be to dedicate part of their efforts towards the "long term
support" (fixing bugs, actual "finishing") of X.Org without introducing new
features. For example, they could address the well-known Xft color emoji crash,
a real example affecting suckless software. Instead, they deliberately choose
otherwise, while presenting Wayland as the new standard, using strong language
to tell off and even openly insult, resorting to petty name-calling, people who
suggest this or who present evidence on why their decisions are wrong. They
didn't even merge independently developed libxft-bgra patch so far! (Yes, it
doesn't solve the entire problem yet, but that's what git is for.)

>it's open source and I cannot force anyone do work on X if they don't want to.

Neither should Wayland be presented as the "be all, end all" of GUI under
GNU/Linux, even moreso since it "isn't in a good state" (fully agree).  After
all those years, someone should begin to wonder if it's worth it at all. Maybe
the general direction should be reevaluated?

>We could absolutely have a full replacement for the X server based on wayland.
>The wayland people won't build it for us though. Neither will the gnome 
>people. 

To use an allegory: it is perfectly fine that they don't want to build our
bridges. But they shouldn't tear down the ones we have, no matter how worn out
or in need of repair they might be. The new ones have design flaws and aren't
even complete.

> You can decide for yourself whether you want to keep whining

Typical use of a strong language as a substitute for having real arguments.

Re: [dev] Wayland compositors

[Tobias Bengfort]

Hi,

I think much of the hate for wayland is misdirected. Don't get me wrong, 
the state of wayland is bad. But IMHO that is not entirely the wayland 
people's fault.


What they did is saying: "Hey guys, we are tired of maintaining X. We 
will start a new project with a tighter focus. The wider linux community 
has to step in for all the parts that we no longer support. Just use 
dbus or something."


This move was not great and also not very well communicated. But hey, 
it's open source and I cannot force anyone do work on X if they don't 
want to.


I think what they intended was that some people mess around with some 
ideas and after a while everyone agrees on a single set of protocols (or 
maybe even a single compositor implementation).


Imagine a scenario where we had a single compositor that had an API for 
window management. That is entirely possible. (I built a window manager 
that uses the sway IPC mechanism a while ago.) Wayland does not prevent 
the old server/window manager separation. But it also does not enforce 
that separation.


Unfortunately the wider community did not come together on this. 
Especially gnome created a bunch of specific solutions that will never 
work outside of the the gnome ecosystem. The coordination that is 
happening at https://gitlab.freedesktop.org/wayland/wayland-protocols is 
negligible. The best thing we have in that direction is wlroots, but 
most major desktops refuse to use it.


Most people in this thread seem to agree that the wayland protocol has 
some improvements, but the lack of features is a dealbreaker. We could 
absolutely have a full replacement for the X server based on wayland. 
The wayland people won't build it for us though. Neither will the gnome 
people. You can decide for yourself whether you want to keep whining or 
actually do something about that.


tobias

Re: [dev] Wayland compositors

[Kyryl Melekhin]

Hello guys,

I recently tried out Wayland and here are some of my thoughts.
They market it as a "shiny new object".  OK. So I compiled all the libs,
and tried the dwl compositor. I like suckless and dwl supposed to be
like dwm but on wayland.

Let's perform a simple test: I open the foot terminal (which is supposed
to be like st but on wayland) and try resizing it. And you as you may guess
that crap lags like it's the 1980's on modern hardware. I do the same thing
under X11 and it is a way more pleasant experience. This is enough to tell
me everything about why wayland sucks. It does not matter, you can say it
does not happen on sway because they implemented something like
Xdamage into the compositor. But the problem is that 90% of the
wms/compositors don't.This is the most fundamental feature wayland
should have - good handling of resize in the damn protocol.
Shows a lot about the design being flawed, have they not learned that
in the 40 years of experience?

I can't just write a program that would run under wayland without
requiring implementation of a specific compositor. If I want to guarantee
that my program won't lag like it's 1980.

I actually quite like the software rendering done by X11, I want to be
able to draw font's and not write entire opegl/vulkan renderer for
font's from scratch. Wayland devs don't care about those because
they live in a bubble where everything is Chrome, Gnome, Kde, etc
where "nobody will ever use this". But it turns out that if you do the math,
there are a lot more programs using X11 to draw stippled lines,
polygons, and wide arcs than there are number of programs in their
perfect world bubble.

I want to have the ability to choose what X11 extensions to use on my
system. The freedom of choice under X is far greater in terms of
customization.

I commend them for trying to keep the protocol small and all.
But if that protocol can't do basic things why do we even need it?
It's redundant because I can just use linux framebuffer and
implement everything myself. I don't need their protocol if
it does not provide enough common functionality, it's just
bloat.

Imagine what they could have done if they just spent 10 years
optimizing every single line of code in X? Push forward for a new
X12 standard, move "weird stuff" into libraries, make it more modular.
They have been doing that in fact they did shrink the code base
to around 500K from 1M in a matter of years. It really looks like somebody
just decided to evade responsibility to favor the investors.
Because at the end of the day, optimization is hard and nobody
cares about half a century old protocol in this "modern world".

You don't have to start from scratch to make something better,
you just have to be stubborn and keep working on the project.

Imagine what would've happened to linux if Linus Torwalds
decided to rewrite the kernel from scratch the next day?
It would have been a complete disaster and failure, it be taking
one step forward and five backwards.

Hopefully you guys can tolerate some of my opinions here.
This is just my first impression, I used Wayland for 5 minutes,
to realize that it is not for me. Not to mention that I would have
to put in a crazy amount of time and work to get back
my x11 workflow on wayland.

And remember, always follow unix philosophy - go for
what works first, optimize it later.

Kind Regards,
Kyryl.

Re: [dev] Wayland compositors

[Markus Wichmann]

On Thu, Sep 16, 2021 at 08:26:27AM +0200, Laslo Hunhold wrote:
> The gaslighting regarding Wayland wasted me a lot of time, as I'm told
> or I read every year that _now_ would be the time to switch to Wayland.

Just like _this_ year is the year of the Linux desktop? And then, when
the market share inevitably fails to materialize, they will claim they
meant next year.

In any case, I believe the idea behind Wayland to be sound, just the
current implementation is not. They just have "a few issues to work
out", and have been doing that for years now. But on the other hand, I
had tried switching to Linux a few times before I actually could stay on
it (even the prettiest pictures cannot make up for lacking hardware
support, and I had problems with Wifi for the longest time), and that
was at some time during the 2.6 line. So maybe Wayland needs another
decade to ripen and mature.

Ciao,
Markus

Re: [dev] Wayland compositors

[Laslo Hunhold]

On Tue, 14 Sep 2021 15:21:58 +0600
NRK  wrote:

Dear NRK,

> Adding to what Laslo has already said:
> 
> I think it's laughable that that wayland devolopers claim wayland to
> be a replacement for X while actively ignoring many use-case and
> forcing their "perfect frame" philosophy onto the users.
> 
> It is _OK_ if the devs prioritize having perfect frame and want to
> work on it more, I think we all want to work on features that are more
> valueable to us. But to actively discard other use-cases is _NOT_ ok.
> 
> I for one have no regards to "perfect frame" and value a crisp low
> latency desktop without running any compositor. This is not possible
> in wayland but perfectly viable in X. Why should I have wayland dev's
> use-cases shoved down my throat? If I wanted to be pushed around by
> devs I'd use proprietary software instead.
> 
> And it's also very funny that the devs (one of them atleast) think
> that instead of making wayland work for these users calling them
> "anti-vaxxers and flat-earters" is the way to go :)
> 
> https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html

good points. In open source, a solution should not shoehorn the users
into very tightly defined use-cases, but instead be flexible. X may be
a monstrosity, but it has shown that it's flexible enough (or rather
that enough work was put into it that it became that way).

Ad hominems against proper criticism are the lowest level in debate.
The gaslighting regarding Wayland wasted me a lot of time, as I'm told
or I read every year that _now_ would be the time to switch to Wayland.
But every time I do, my entire workflow breaks, and fixing it is
extremely hacky and fragile.

With best regards

Laslo

Re: [dev] Wayland compositors

[NRK]

Hi,

Adding to what Laslo has already said:

I think it's laughable that that wayland devolopers claim wayland to be
a replacement for X while actively ignoring many use-case and forcing
their "perfect frame" philosophy onto the users.

It is _OK_ if the devs prioritize having perfect frame and want to work
on it more, I think we all want to work on features that are more
valueable to us. But to actively discard other use-cases is _NOT_ ok.

I for one have no regards to "perfect frame" and value a crisp low
latency desktop without running any compositor. This is not possible in
wayland but perfectly viable in X. Why should I have wayland dev's
use-cases shoved down my throat? If I wanted to be pushed around by devs
I'd use proprietary software instead.

And it's also very funny that the devs (one of them atleast) think that
instead of making wayland work for these users calling them
"anti-vaxxers and flat-earters" is the way to go :)

https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html

- NRK

Re: [dev] Wayland compositors

[Laslo Hunhold]

On Wed,  8 Sep 2021 20:34:20 +
Hadrien Lacour  wrote:

Dear Hadrien,

> This, it would have been a great goal to modularize X11 and keep the
> worthy parts, not just reduce it to an exercise in "minimalism" (and
> complete lack of portability) and expect the free FOSS market to
> magically solve the remainder.

really well put, I totally agree!

> A good rant. Let me add my biggest problem: global keyboard grabbing
> isn't possible unless done by the compositor, so something like
> bspwm+sxhkd doesn't look possible right now.

Thanks! Yes, this is a good point. On a related note, the coordinate
system is messed up as well. It's not possible to position a window
somewhere specifically (e.g. at the top), which makes dmenu impossible.

I understand that this was, again, done to make Wayland ultra-flexible,
but if you really want to go all Zen you could at least offer a
function allowing you to request to be positioned somewhere. If your
fish-eye-compositor with bloody non-euclidean geometry denies this
request, so be it, but 99% of the cases still cover the traditional
rectangular desktop setup. What a mess this is!

With best regards

Laslo

Re: [dev] Wayland compositors

[Hadrien Lacour]

On Wed, Sep 08, 2021 at 08:35:33PM +0200, Laslo Hunhold wrote:
> On Tue, 31 Aug 2021 14:28:29 +0100
> Nick  wrote:
>
> Dear Nick,
>
> > Any thoughts, experiences, recommendations?
>
> the discussion has been very fruitful. Let me share my thoughts.
>
> Wayland the protocol is actually rather simple. It's a very thin
> messaging layer between a compositor and clients, nothing more.
> But this is exactly the problem: It's too thin and the
> Wayland-developers didn't dare to go beyond a minimal set of things.
>
This, it would have been a great goal to modularize X11 and keep the worthy
parts, not just reduce it to an exercise in "minimalism" (and complete lack of
portability) and expect the free FOSS market to magically solve the remainder.

> All of the things that are breaking are those based on
> (compositor-specific) Wayland-extensions which add functionality you'd
> expect (gamma control, screen sharing, etc. etc.). I will never forgive
> the Wayland-developers for their lack of courage.
>
> We're talking about the next generation of display/window managers, and
> they messed it up so badly! Just a few things that come to mind:
>
>- network transparency is a _good_ thing and was thrown away way too
>  easily. I like being able to run GUI-applications from time to
>  time via ssh. Most of the time they are just basic
>  GUI-framework-programs you could "stream" very efficiently, but if
>  you're talking about composited surfaces, I would expect Wayland
>  to do that for me too, via a compressed stream or something.
>  It's trivial to stream Ful-HD-Video P2P using modern compression
>  algorithms, why wasn't this taken into consideration?
>  People are always talking about moving away from the single
>  computer and into the "orbit" (see Urbit, etc.). Today's
>  technology makes it possible to be much more flexible in this
>  regard.
>- color management was totally ignored. This could've been a strong
>  point for Wayland, but instead they made it even worse than in X,
>  which is actually a difficult feat. We need to move away from the
>  sRGB-monoculture, especially because it's not bloaty to actually
>  support proper colour management and it has tangible benefits.
>- everything about Wayland is hacky and deeply integrated into
>  Linux, but what for? To get "perfect frames", as it is often said?
>  This could've been done so much better, for example by going
>  vector-first. Most stuff in a GUI can easily be represented by
>  vector-data, which is very sparse. You do have bitmap-surfaces
>  from time to time (video player, browser, games, etc.), but it
>  would've been a very interesting and radical approach. The
>  advantage of this is that you don't need to think about dpi and
>  other shit except in those bitmap surfaces. All the rasterization
>  would be the last step and not intrinsic to the protocol itself,
>  but just the compositor.
>
> Anyway, to sum it up: Probably nobody here is really a fan of X, but
> it's what we have. Wayland is an underwhelming mess and they really
> dropped the ball here. The mix of (often incompatible and competing)
> extensions that are made up and forced upon us (while leading to more
> and more userspace-applications relying on them and unexpectedly
> breaking in vanilla Wayland-compositors that don't want to be tainted
> with the garden-variety of extensions) is just horrible.
>
> I used to have enthusiasm about Wayland, but now this feeling has
> completely been replaced with pity. They really dropped the ball on
> this one and I will not waste any more time with it.
>
> With best regards
>
> Laslo
>
A good rant. Let me add my biggest problem: global keyboard grabbing isn't
possible unless done by the compositor, so something like bspwm+sxhkd doesn't
look possible right now.

Re: [dev] Wayland compositors

[Laslo Hunhold]

On Tue, 31 Aug 2021 14:28:29 +0100
Nick  wrote:

Dear Nick,

> Any thoughts, experiences, recommendations?

the discussion has been very fruitful. Let me share my thoughts.

Wayland the protocol is actually rather simple. It's a very thin
messaging layer between a compositor and clients, nothing more.
But this is exactly the problem: It's too thin and the
Wayland-developers didn't dare to go beyond a minimal set of things.

All of the things that are breaking are those based on
(compositor-specific) Wayland-extensions which add functionality you'd
expect (gamma control, screen sharing, etc. etc.). I will never forgive
the Wayland-developers for their lack of courage.

We're talking about the next generation of display/window managers, and
they messed it up so badly! Just a few things that come to mind:

   - network transparency is a _good_ thing and was thrown away way too
 easily. I like being able to run GUI-applications from time to
 time via ssh. Most of the time they are just basic
 GUI-framework-programs you could "stream" very efficiently, but if
 you're talking about composited surfaces, I would expect Wayland
 to do that for me too, via a compressed stream or something.
 It's trivial to stream Ful-HD-Video P2P using modern compression
 algorithms, why wasn't this taken into consideration?
 People are always talking about moving away from the single
 computer and into the "orbit" (see Urbit, etc.). Today's
 technology makes it possible to be much more flexible in this
 regard.
   - color management was totally ignored. This could've been a strong
 point for Wayland, but instead they made it even worse than in X,
 which is actually a difficult feat. We need to move away from the
 sRGB-monoculture, especially because it's not bloaty to actually
 support proper colour management and it has tangible benefits.
   - everything about Wayland is hacky and deeply integrated into
 Linux, but what for? To get "perfect frames", as it is often said?
 This could've been done so much better, for example by going
 vector-first. Most stuff in a GUI can easily be represented by
 vector-data, which is very sparse. You do have bitmap-surfaces
 from time to time (video player, browser, games, etc.), but it
 would've been a very interesting and radical approach. The
 advantage of this is that you don't need to think about dpi and
 other shit except in those bitmap surfaces. All the rasterization
 would be the last step and not intrinsic to the protocol itself,
 but just the compositor.

Anyway, to sum it up: Probably nobody here is really a fan of X, but
it's what we have. Wayland is an underwhelming mess and they really
dropped the ball here. The mix of (often incompatible and competing)
extensions that are made up and forced upon us (while leading to more
and more userspace-applications relying on them and unexpectedly
breaking in vanilla Wayland-compositors that don't want to be tainted
with the garden-variety of extensions) is just horrible.

I used to have enthusiasm about Wayland, but now this feeling has
completely been replaced with pity. They really dropped the ball on
this one and I will not waste any more time with it.

With best regards

Laslo

Re: [dev] Wayland compositors

[Tobias Bengfort]

Hi Nick,

thanks for sharing dwl. I started writing some patches and it really 
feels very close to dwm. Not fully there yet, but close.


also: don't feed the trolls

tobias

Re: [dev] Wayland compositors

[Nick]

Quoth Страхиња Радић:
> On 21/09/08 01:36, Nick wrote:
> > The fact that the Jitsi devs closed 
> > the bug as "not much we can do on our side" doesn't mean "wayland 
> > broke it and we can't fix it".
> 
> It's exactly the same thing.

In this instance it isn't, maybe I should have been more verbose.  
The issue was with web browser support for wayland screen sharing 
stuff, so Jitsi couldn't fix it theirselves, but it is now well 
integrated and supported in browsers, and therefore by extension 
Jitsi.

> The issues listed show a pattern and the impact of breaking with a
> long-standing, time-tested tradition just for the sake of doing something 
> "new"
> and "different". "New" doesn't automatically mean "good".

True, this is clearly a case where the majority of X developers 
decided it was worth the pain of starting again with a fresh design.  
There are pros and cons to that. In this case I think it sounds like 
it's worth it, as the end result should be a cleaner system with 
less code and more reliability, and I'm happy to pay the short term 
cost of changing some programs I use and learning how to do things 
differently in some cases. Obviously for some people the costs will 
be different, and the benefits don't seem worth it.

It's frustrating to feel like you have so little agency over the 
direction of such decisions - that's one of the things that attracts 
lots of us to suckless - but to some extent that's inevitable with 
large projects like this. As you say, I have little doubt that X 
will continue to receive some attention and support for a long time 
to come, even if not so much from the current core team.

> You haven't mentioned the other points, just some of the major ones being the
> issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, 
> but
> why just erase it in favor of GNOME monopoly? I'm using no desktop 
> environment,
> I'm using dwm, but many of its key features are not supported by Wayland. 

>From what I could see on that list, the KDE and XFCE issues 
mentioned are all things which are being worked on or have already 
been addressed by those projects. I don't really see how Wayland is 
leading to a GNOME monopoly, there are plenty of other compositors 
out there with more on the way.

I'm going to bow out of this conversation now, lest it become even 
more interminable for everyone else! But thanks for sharing your 
opinions and thoughts about it, it's (almost) always good to be 
challenged, even if it doesn't result in minds being changed :)

Nick

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/08 01:36, Nick wrote:
> The fact that the Jitsi devs closed 
> the bug as "not much we can do on our side" doesn't mean "wayland 
> broke it and we can't fix it".

It's exactly the same thing.

> the screen recording / sharing stuff - it works differently on 
> Wayland (for not-bad reasons),
[...]
> good reasons (thinking of the "prevents GUI applications from 
> running as root" and "breaks windows rasing/activating themselves").

The issues listed show a pattern and the impact of breaking with a
long-standing, time-tested tradition just for the sake of doing something "new"
and "different". "New" doesn't automatically mean "good".

They also show the attitude of the developers responsible for Wayland. I don't
like it when the "developers" tell the users what is good for them, especially
when they are being opinionated and stubborn for no reason at all.  Let the
users decide how they are using the software. Let us be able to make mistakes! 

It is the same line of thought as when we compare C to a language like Rust. One
of the key reasons why C is better than Rust and similar overprotecting
opinionated languages, is because it gives user the freedom to do whatever he
wants, mistakes included. In this, C is closer to machine language, and thus
more powerful, more expressive, allowing finer control.

Similar thing to Wayland happened with systemd, the developers responsible for
it were acting unreasonably and immaturely when confronted with different
opinions. Whenever one lacks civility in communication and resorts to
swearwords, that shows faulty of his cause and a weakness of his conviction.

You haven't mentioned the other points, just some of the major ones being the
issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, but
why just erase it in favor of GNOME monopoly? I'm using no desktop environment,
I'm using dwm, but many of its key features are not supported by Wayland. 

Again and finally, I don't want to have to change my software-using habits just
because some "developer's" decision. I want to choose what software I use and
how. Thankfully, there are free licenses, and no free software is ever truly
"dead". If Wayland becomes enforced like systemd, in time there will be a
solution comparable to runit/OpenRC/s6.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Nick]

Quoth Страхиња Радић:
> On 21/09/08 12:28, Nick wrote:
> > honest I found the arguments made there to be largely unconvincing, 
> 
> Any argument in particular and why?

A lot of the "Wayland breaks" examples don't seem to be fairly 
reporting on the actual issues. The jitsi screen sharing issue, for 
example, has reports that it works fine for fedora, but it's just 
the case that (at least when the bug was being discussed, over a 
year ago), the integration of xda-desktop-portal into the system of 
some users hadn't happened yet. The fact that the Jitsi devs closed 
the bug as "not much we can do on our side" doesn't mean "wayland 
broke it and we can't fix it". The same is true of at least most of 
the screen recording / sharing stuff - it works differently on 
Wayland (for not-bad reasons), so some software is redundant, and 
others needed to be updated to use new APIs, and unsurprisingly the 
proprietary crap is the last to be updated. But ultimately, the 
important tasks represented (screen sharing & screen recording) do 
work fine under wayland.

The other headings are less important, I'd say, and seem to either 
fall under same answer as above (for which the answer is often just 
to use different tools that are built for wayland), or non-terrible 
side effects things that are intentionally done differently, for 
good reasons (thinking of the "prevents GUI applications from 
running as root" and "breaks windows rasing/activating themselves").

That's my reading of that gist, anyway.

Re: [dev] Wayland compositors

[Страхиња Радић]

By the way, here's another article not on Github (but linked from that page):

https://tildearrow.org/?p=post&month=2&year=2021&item=antihs



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/08 12:28, Nick wrote:
> honest I found the arguments made there to be largely unconvincing, 

Any argument in particular and why?

> * I'm thinking in particular of the repeated "emojis broke my st" 
>   mails, caused by a bug in Xft that noone upstream seems to care much
>   about fixing, and the fact that surf is a really just a nice
>   interface atop the hulking edifice of webkit2/gtk+

This is the fault of X developers, who decided to dedicate their time entirely
to Wayland. In their eyes, Wayland is the continuation of X.Org.

It is clear by now that Wayland is influenced by big corporations, RedHat in
particular, which is also forcing things like GNOME, systemd and Rust in the
Linux kernel upon the users.

Wayland sucks. X.Org sucks too, but it is still much better than Wayland.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Nick]

Hi Maarten et al,

Many thanks for your replies, this was very handy to read.  
Interesting to hear that sxmo is moving in the wayland direction, 
too. I haven't managed to get around to actually trying wayland yet, 
as as ever my attention has been pulled in too many different 
directions. But I'll get there.

Thanks to Страхиња Радић, too, for the link to the "wayland is bad" 
github gist. The idea that a github gist is the place for such 
discussion is funny to me, given that github's model and interface 
is hardly suckless, but hey ho, such is modern internet life. To be 
honest I found the arguments made there to be largely unconvincing, 
and while the idea that compositing is not separated from window 
management certainly seems dodgy on first reading, the wayland way 
seems much nicer than X to my eyes. I'm reading the Wayland book at 
the moment , so soon my opinion will be 
better informed - don't take my words too seriously on the matter 
for now.

The issue with suckless software depending on sucky libraries 
outside of their direct control is an enduring one* with no easy 
fixes, but it looks to me like the move away from X should go some 
way to (hopefully) more solid foundations to build on in the future.  
I'm an optimist, in this way.

Anyway, thanks again for all your thoughts.

Nick

* I'm thinking in particular of the repeated "emojis broke my st" 
  mails, caused by a bug in Xft that noone upstream seems to care much
  about fixing, and the fact that surf is a really just a nice
  interface atop the hulking edifice of webkit2/gtk+

Re: [dev] Wayland compositors

[Jochen Sprickerhof]

* Hadrien Lacour  [2021-08-31 15:43]:

On Tue, Aug 31, 2021 at 03:49:43PM +0200, Maarten van Gompel wrote:


dwm -> sway (granted, not the same thing)
svkbd -> wvkbd  (see https://github.com/jjsullivan5196/wvkbd/pull/2)
st -> foot
dmenu -> bemenu



If only there was an equivalent to lemonbar and bspwm+sxhkd (not possible from
what I understand; unless the compositor launches the binary, maybe?).

https://github.com/majestrate/wterm looks like a better concept but foot is
maintained and doesn't bundle wld, at least.


There is also

https://github.com/deadlyshoes/st-wl

Which has a wl.c, similar to the x.c in st and is thus easy to rebase on 
the current st master.


signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Hadrien Lacour]

On Tue, Aug 31, 2021 at 03:49:43PM +0200, Maarten van Gompel wrote:
> Hi Nick et al,
>
> With Sxmo we're currently also moving towards wayland (we'll have to
> reinvent what the X in our name means then).  We found that, especially
> on the Pinephone, the performance under Wayland is simply superior to
> that on X11. We settled on sway to replace dwm, as dwl still lacks the
> maturity we need and sway has that going for it. I agree it comes with
> maybe a few too many bells & whistles as we'd like. Though of course, by
> definition a wayland compositor has a considerably higher complexity
> than an X11 window manager anyway.
>
> We will also keep supporting X and the suckless stack, but
> Wayland will become the default in the very near future for us.
> Unfortunately this means we had to look for comparable alternatives for
> the suckless software stack we've grown attached to. But fortunately
> there are people taking up wayland-focused initiatives with a similar
> philosophy. Thus far we have:
>
> dwm -> sway (granted, not the same thing)
> svkbd -> wvkbd  (see https://github.com/jjsullivan5196/wvkbd/pull/2)
> st -> foot
> dmenu -> bemenu
>

If only there was an equivalent to lemonbar and bspwm+sxhkd (not possible from
what I understand; unless the compositor launches the binary, maybe?).

https://github.com/majestrate/wterm looks like a better concept but foot is
maintained and doesn't bundle wld, at least.

Re: [dev] Wayland compositors

[Maarten van Gompel]

Hi Nick et al,

With Sxmo we're currently also moving towards wayland (we'll have to
reinvent what the X in our name means then).  We found that, especially
on the Pinephone, the performance under Wayland is simply superior to
that on X11. We settled on sway to replace dwm, as dwl still lacks the
maturity we need and sway has that going for it. I agree it comes with
maybe a few too many bells & whistles as we'd like. Though of course, by
definition a wayland compositor has a considerably higher complexity
than an X11 window manager anyway.

We will also keep supporting X and the suckless stack, but
Wayland will become the default in the very near future for us.
Unfortunately this means we had to look for comparable alternatives for
the suckless software stack we've grown attached to. But fortunately
there are people taking up wayland-focused initiatives with a similar
philosophy. Thus far we have:

dwm -> sway (granted, not the same thing)
svkbd -> wvkbd  (see https://github.com/jjsullivan5196/wvkbd/pull/2)
st -> foot
dmenu -> bemenu

Regards,

--

Maarten van Gompel

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
Telegram:   proycon  IRC: proycon (libera.chat + oftc)
Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
Twitter:https://twitter.com/proycon

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/08/31 02:28, Nick wrote:
> Hi all,
> 
> I'm thinking it would be fun to play around with Wayland, so was 
> looking at different compositors (which do window management plus 
> other stuff). Has anyone else on the list taken Wayland for a spin 
> and had any experience with them?
> 
> From a search around the 3 that look interesting to me, a dwm user 
> for many years, are:
> - velox - written by Michael Forney, described as "inspired by dwm 
>   and xmonad"
> - sway - i3 for Wayland, undoubtedly mature, undoubtedly more 
>   features than I'd prefer
> - dwl - "dwm for Wayland", looks nicely dwm-ish, though no built-in 
>   status bar so I guess I'd have to find some external software to 
>   provide that.
> 
> Any thoughts, experiences, recommendations?
> 
> Nick
> 

https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277



signature.asc
Description: PGP signature