Thank you so much! This will come in handy in the future when I'll try to build my own GUI library! Please, consider updating in 2-3 years, in case Wayland changes its architecture!
Very nice! I tried writing my own wayland client without using libwayland, but unfortunately the official spec basically assumes you are using libwayland. So in some more complex requests such as wl_shm.create_pool the spec doesn't actually describe the wire messages only the call into libwayland, so its a pain to dig through the source to figure it out. I don't think that's a good thing since libwayland should just be a reference implementation of the spec, not the spec itself, but oh well I guess most people would just prefer to use it anyways.
Cool channel though, I absolutely agree with your philosophy on the value of not being afraid to just build things from scratch and really understand how they work.
The X11 is divided in two parts, the client and server. And those parts doesn't need to be running on the same machine. The window manager, is just an ordinary program, that can control and place other clients windows. So a window manager can be written in about 200 lines of code. So basically, to decide what window should be positioned on the screen or not, is decide by window manager, you don't need any support from the client. In Wayland you MUST have support from the client to be able to iconify or maximize a client window. If the client is sleeping, you can't iconify the window (basically like MS Windows). As long as the WM client runs, X11 can move windows around without support from the client.
Aren't client in Wayland supposed to just render something into the memory and that's all? In terms of server it should just be "not render this window to the actual screen", right?
I’m not an expert either but I’m guessing that is reading hours and hours of documentation, searching and scraping the web in the forums. Lots of trial and error. Patience and persistence.
Worked through it, highly recommend. Great walkthrough. I hope others find this, it should be linked in the fd.o docs along with the book. Nice work! Thank you.
the thing people still do not seem to understand is, that "wayland" actually does nothing. it does not exist, it is not a piece of software. its a specification, and just that. wayland describes how you talk to _A_ compositor, it is not one of on its own. its just the description of an api. basically the complete introduction of this video is factually wrong.
Wayland exists as a server for the compositor. You are correct to an extent that Wayland is almost entirely a specification for communication between the individual applications and the compositor, and I shouldn't have said "Wayland is a compositor", though I'd still argue that Wayland "exists" and "runs" as the network of the clients and servers.
It's funny, as bad as X11 is, somehow Wayland's API manages to be 10x more incomprehensible. An hour and 20 mins to set up a not even a fully featured window is ridiculous. The state of programming is depressing.
@@plasmahvh I would say that it's not as bad as it may seem. It clearly lacks some features which are getting worked on. I believe the lack of wide adaptation is a huge reason for its slow development and bugs. It was only this year that mainline distros announced pure use of Wayland (no longer being the second option)
Excellent tutorial! I lost it every time you yelled f**k when the compiler complained
Very helpful, thank you! The fact that you were able to do this so smoothly live is really impressive
Thank you so much! This will come in handy in the future when I'll try to build my own GUI library! Please, consider updating in 2-3 years, in case Wayland changes its architecture!
Really good tutorial, looking forward for more wayland tutorials from you
Very nice! I tried writing my own wayland client without using libwayland, but unfortunately the official spec basically assumes you are using libwayland. So in some more complex requests such as wl_shm.create_pool the spec doesn't actually describe the wire messages only the call into libwayland, so its a pain to dig through the source to figure it out. I don't think that's a good thing since libwayland should just be a reference implementation of the spec, not the spec itself, but oh well I guess most people would just prefer to use it anyways.
Cool channel though, I absolutely agree with your philosophy on the value of not being afraid to just build things from scratch and really understand how they work.
What was your use case for not using libwayland? Learning the wire protocol, wanting a static build or something else?
The X11 is divided in two parts, the client and server. And those parts doesn't need to be running on the same machine. The window manager, is just an ordinary program, that can control and place other clients windows. So a window manager can be written in about 200 lines of code.
So basically, to decide what window should be positioned on the screen or not, is decide by window manager, you don't need any support from the client. In Wayland you MUST have support from the client to be able to iconify or maximize a client window. If the client is sleeping, you can't iconify the window (basically like MS Windows). As long as the WM client runs, X11 can move windows around without support from the client.
Aren't client in Wayland supposed to just render something into the memory and that's all? In terms of server it should just be "not render this window to the actual screen", right?
Thanks for sharing this, indeed very useful for a beginner like me. I really appreciate it.
What i want to know is where you learn all of these different things because obviously i wont get very far only watching videos
I’m not an expert either but I’m guessing that is reading hours and hours of documentation, searching and scraping the web in the forums. Lots of trial and error. Patience and persistence.
On a modern kernel, can you use memfd instead of shm?
Worked through it, highly recommend. Great walkthrough. I hope others find this, it should be linked in the fd.o docs along with the book. Nice work! Thank you.
I need to run a c# Desktop application using weston on ubuntu??
no
Your color scheme makes it hard to read your code (#include is near invisible).
Great video, and explanation.
how are you theming your setup???
TY man, so long video, but so interesting!
the thing people still do not seem to understand is, that "wayland" actually does nothing. it does not exist, it is not a piece of software. its a specification, and just that. wayland describes how you talk to _A_ compositor, it is not one of on its own. its just the description of an api.
basically the complete introduction of this video is factually wrong.
Wayland exists as a server for the compositor. You are correct to an extent that Wayland is almost entirely a specification for communication between the individual applications and the compositor, and I shouldn't have said "Wayland is a compositor", though I'd still argue that Wayland "exists" and "runs" as the network of the clients and servers.
Are you using external libs like wlroots?
"wlroots" is used to create a Wayland compositor, not a client.
I'm the thousandth subscriber!
Sat, December 7. 12:41AM.
amazing video
can relate too much @ 29:08
Hahahaha! Me too! The language I design will have no imports and everything will be automatically searched ;)
Will next time zoom in or take a larger font it's terrible I need a magnifier to see that sh**
It's funny, as bad as X11 is, somehow Wayland's API manages to be 10x more incomprehensible. An hour and 20 mins to set up a not even a fully featured window is ridiculous. The state of programming is depressing.
Well it would clearly be easier if he used a toolkit like GTK, but the point of the video is to show how the Wayland protocol is used under the hood.
@@an0nsaiko890 and it's not good. 15 years of development and it's still not ready for most people. ridiculous
@@plasmahvh I would say that it's not as bad as it may seem. It clearly lacks some features which are getting worked on. I believe the lack of wide adaptation is a huge reason for its slow development and bugs. It was only this year that mainline distros announced pure use of Wayland (no longer being the second option)
Having an easier API doesn’t make your protocol or server better
@@thebatchicle3429easier and comprehensible are two different things.
f* callback hell
zero to window would be without wayland-client...
Could you speak up a little?
crank the vol boy
80 minutes for a barely functional window 😂 Wayland is a joke!
well winapi is worse honestly
as it should be