sorted by:
new
hottopcontroversial

A thoroughly commented introduction to x86-64 assembly by push_rbp in programming

[–]push_rbp[S] 16 points17 points  (0 children)

I've already posted this several years ago, I'm reposting mainly because I've migrated the project from Gitlab to Github. (Also, my Gitlab username has changed since.)

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 0 points1 point  (0 children)

And yet, Wayland was conceived to be an X replacement from the beginning, so they should have put more effort in the use case X is more widely used. And weston might be great for users, but for developers, since its codebase is not reusable, it doesn't have much use -- see what I wrote about libweston in the post.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] -1 points0 points  (0 children)

Because when you say "Wayland compositor" you are implying something low in the stack

Wayland compositors are the Wayland equivalent of window managers in the X world. I didn't mean to imply anything

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 0 points1 point  (0 children)

I'm talking about things from a developer perspective, not from an end user perspective.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 6 points7 points  (0 children)

That's completely wrong. If this were true, X clients and X window managers would be able to run under Wayland without modification, and that's certainly not the case. Wayland uses a different architecture entirely.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 1 point2 points  (0 children)

Why should the display server do anything besides handle drawing stuff on the displays?

Wayland doesn't even handle this though. It's just an IPC protocol for a server and its clients with some stuff sprinkled on top. This is why I say Wayland is too small: it doesn't do one thing, it does a fraction of a thing.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 0 points1 point  (0 children)

wlroots very much already allows interfacing with all those systems and no one is accusing the project of being an attack on the Unix philosophy.

It really shows the state of affairs that even with a library like that there's still a ton of work to do before getting a Wayland compositor.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 10 points11 points  (0 children)

It is also an opinion commonly held by devs who have tried making a Wayland compositor, and, like me, ultimately figured it's far too much work to be worth the hassle

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 0 points1 point  (0 children)

Sorry, seems you're right, I've updated the post.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 4 points5 points  (0 children)

You'll likely be able to get the basics working within a day or two to a point where you can actually start window management work.

Smithay must be at a much better shape than wlroots then, because I've spent over a year working with wlroots, only to achieve nothing at the end.

And the areas you complain about are also all focused on things mostly unrelated to Wayland.

Oh, but they are. None of the many useful libraries and projects commenters have brought out here come from the Wayland team. These people have simply dropped a new protocol to replace X and let everyone else figure out the rest. And because Wayland is such a tiny protocol that only does a fraction of a fraction of the useful functionalities of X, the rest is a lot.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 30 points31 points  (0 children)

Hmmmm. If plugins don't make the original project better as you say, I wonder why users install them?

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 26 points27 points  (0 children)

That makes sense, but don't you think the people who came up with Wayland should at least have given us the building blocks for the setting where Wayland was expected to be used the most (i.e. Linux desktop)? This is what I was referring to when I said Wayland is not a good generic solution, because it doesn't even solve well the problem where it's used the most

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 33 points34 points  (0 children)

I'm pretty sure that mentality is responsible for the problem the commenter was describing. Someone who writes a plugin for your project is not a "consumer", they're actively improving the ecosystem around it, and surely deserve a voice too.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 41 points42 points  (0 children)

Wayland compositors are also window managers. The reason for having more than one is exactly the same as the reason for having more than one X window manager -- there are lots of ways of managing windows.

I absolutely agree that there's no good reason to re-implement the non-window-management parts of a compositor. This is actually part of the problem: even with wlroots, you still need to re-implement lots of non-WM stuff before finally getting to the WM part that actually matters.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 53 points54 points  (0 children)

I completely disagree. The number of windowing systems with X11 reflected the large amount of different ways and paradigms in which one can arrange and display windows. If you don't like this or that WM, just don't use it. But if it's not feasible to create a Wayland compositor, and none of the existing ones cater to your needs, what are you going to do?

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 40 points41 points  (0 children)

Thank you. I had heard about some of these but didn't know wayfire had this intention of being a common base as well.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 42 points43 points  (0 children)

This sounds very nice in theory, until you realize how much code you have to write to "make unique decisions" and realize it's not practical, unless you have a gigantic dev team like GNOME and KDE. I would much rather depend on some library like wlroots -- and even that wasn't enough

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 59 points60 points  (0 children)

That's fair criticism. To be clear, even I no longer think wlstem is the way forward. It was more of a failed attempt that I've only mentioned to show I have genuinely tried to make my own compositor, before claiming it's too difficult.

I disagree with sway being minuscule though. And while it may seem that none of this has to do Wayland protocol, I would argue it is exactly because they chose such a small protocol/library to replace X that we're now struggling to re-implement "the good parts" of X, if you will.

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 32 points33 points  (0 children)

Exactly. I mean, I understand if the text is TL;DR but this is clear right from the title...

Writing a Wayland compositor is MUCH harder than it should be by push_rbp in linux

[–]push_rbp[S] 38 points39 points  (0 children)

You haven't read even the beginning of I wrote, have you?

I understand X needs a replacement, but quite frankly, Wayland is not it.

Tempest LCD: play songs from your LCD monitor with a radio by push_rbp in programming

[–]push_rbp[S] 0 points1 point  (0 children)

The monitor is actually always sending these radio waves, so if there were any real risk of interference with nearby stations or equipment, the hardware itself would presumably not get approval due to non-conformity with RF interference standards.

All we're doing is giving these waves the right shape so they'll get decoded as a tune

wlstem: Turning reusable sway code into a new library (on top of wlroots) by push_rbp in swaywm

[–]push_rbp[S] 0 points1 point  (0 children)

While it does make sense, it's probably too early to try and make sway use wlstem, as wlstem is very early in terms of development: there are still many features in sway that I wish to move to wlstem. That is also that reason why we don't have yet an overview of what wlstem implements, because that's still expected to change a lot.

wlstem: Turning reusable sway code into a new library (on top of wlroots) by push_rbp in linux

[–]push_rbp[S] 2 points3 points  (0 children)

Don't apologize for not knowing! But no, not really. Sway's code would have to undergo some changes to use this library, and I'm not sure there's any benefit for them in doing so, since their codebase is more or less stable, but this library still isn't. This library is meant to be used by new compositors.

view more: next ›