KDE Server Decoration Protocol Proposed For Wayland-Protocols

[arboy84]

You might want to check with Canonical about how easy writing a useable windowing and compositing system is.

[oiaohm]

" X is crap and Wayland is the future."
You want to bet on that? I can bet that X will out-live wayland. Of course X is not the future, but as soon as something far better than wayland appears, wayland can become obsolete very soon. The reason that wayland seems to have a future is because there is nothing else to compete with it, since no real professionals want to replace x and wayland. I bet google is very happy that wayland/linux is bad as a desktop. Apple the same. But if somebody appears with something great, easy to use, safe code, easy to maintain and to extend, then the days of wayland are counted. I already have my nice own cross platform GUI Framework (far from complete) which is such a pleasure to use (Vulkan as rendering backend, and XCB as windowing system).
I will wait at most one more year, and see how Fuchsia OS (google) develops, and if i notice it's indeed the future, I will switch to Fuchsia. If not, then I will write my own wayland replacement (compositor and client). One might think: this is a lot of work: Not that much if you have good design. For example check out the code of XBoard (chess), and you will see how many lines of code it has, how complex it is to read and to understand. Then check out similar projects written in c++ or java, and you'll see that it's nothing special/hard.

Reality here there are a long list of people who had the idea of writing their own X11 replacement, Ywindows , directfb ...... Basically stack of grave yard projects.

C++ and Java project have died quite quickly in this area. Talking against C showed you were clueless. Did not you notice XCB and Vulkan is written in C this is intentional. You want to make something programming language neutral with nice solid standards on how the binaries will work It is C interfaces or nothing.

C++ that Fuchsia OS uses is a nightmare because the C++ standard does not define how name mangling and memory management and many other things are done and is left purely up to the compiler. So Fuchsia updates it compiler and your applications/drivers could be broken. So 100 percent the define of not fun.

https://www.phoronix.com/scan.php?page=news_item&px=Rust-Wayland-Skylane

Also wayland being a protocol standard as above shows the interfaces of Wayland do not have to be implemented in C. But this also requires the protocol to be stable.

https://github.com/wayland-project/w.../master/stable number of stable features in the Wayland protocol 2.
https://github.com/wayland-project/w...aster/unstable number of unstable features in the Wayland protocol 14.

Why so many features stuck in unstable. Its the peer review process most of the protocols are having faults that need fixing. Yes a lot of people have made attempts at doing what wayland has doneand a lot of the projects are dead. The reality is is not easy to get it right.

So as the different unstable and proposed features get merged into Wayland after passing peer review(that not easy) will that wayland different to what we know now yes. Like one is the means to pass though complete keyboard to virtual machines and other items that you currently cannot do under X11 and get this wrong you can have locked the user out of the system. If you think you can create all these features without solid peer review go right ahead and try but don't be surprised when you get almost no support and make major end user hurting mistakes. The history of the dead project says that your idea of go out and write a wayland replacement is doomed to failure if you cannot get enough support.

Wayland only gets off the ground because it has support of x.org being the most common X11 server in use and being able to integrate features like libinput into that X11 server to force hardware to support it. Cipri where is your ability to force hardware vendors to support you. If you don't have that you are just going to start another directfb class project that in time will die.

Also the volume of work to remove X11 mandate from graphics drivers has been absolutely insane. There is also a lot of lower graphical work that is still on going as well.

If this was an idea to start a flame war forget it. Server Decoration Protocol if that gets into mainline wayland and becomes a commonly supported feature a lot of the developer hate of wayland will go away. By the way client side render makes sense when you need most performance. But there is most likely a lot of cases that developers will not care about a little performance loss on Server Decorations if it means they don't have to-do them.

[cipri]

Reality here there are a long list of people who had the idea of writing their own X11 replacement, Ywindows , directfb ...... Basically stack of grave yard projects.

C++ and Java project have died quite quickly in this area. Talking against C showed you were clueless. .

Sorry my friend, I'm talking against C, because I have quasi already parts of my replacement for Wayland done! Much nicer. I have even developed my own IPC framework based on shared memory. Now I can use ipc nearly as effortless like using c++ threads.
Another example is the usage of C in programming microcontrollers. Also there I wrote my own hardware abstraction layer in c++14. The result is the following: For what others need days to write thousands of lines of C code. I need about 10 minutes of very intuitive and easy to read c++14 code. Yes i do give up some speed by not doing direct register programming, but in many cases speed is not the problem, you don't need to get 100% out of your mcu.

Against Vulkan I don't complain because there is Vulkan-hpp which is a considerable help, and because it has cleaner design than wayland. Vulkan is clear, you get the documentation and you can start coding. Wayland is not. I tell you this because I did read the documentation many times, perhaps you didn't!
Check out how fast Vulkan appeared, and also many books. Now comapre it to wayland. Where are the wayland books?
I don't have anything against C when it's design and usage is acceptable, but wayland is not, and I say this because i spent hundreds or thousands of hours with wayland code and tutorials. Before digging into wayland i was a wayland fan too.
You can make a C11 interface, here is not my problem, but the underlying design in the case of wayland should have been done with c++. My own Framework is based heavely on c++17 (and parts of the future c++20, the already voted TS), but the user can use it nearly a like C11 library . Everywhere just smart pointers, very little chances to do something wrong. Effortless multi-window applications with multiple threads impemented in a way that you don't have to think about race conditions . Yes I also built upon C libraries like vulkan, xcb, but in a more robust and isolated way. The unsafe code is very good isolated in the framework and kept small and easy to read. The user doesn't have to care and know about it.
For my needs XCB is fine so far. It doesn't force me like wayland into using global functions/variables.
And like I wrote before, check out the XBoard code and try to understand it and imagine how easy it's to extend and to maintain.

Saying that Wayland is a protcol and does not have to be implemented in C, this sadly is not quite true. At least you have to link against the c library libwayland-client.
This was at the beginning also my hope, to start just by the protocol and write everything in c++, I even did that for the client part, till I had to notice that you are forced into the dependency of libwayland-client if you want vulkan to work.

My framework already supports xcb (next on the plan is win32, but first i have to improve the framework itself) and perhaps later i will also port it to android (which i expect to be harder to do), but I'm also looking out for Fuchsia OS since it might be a replacement for android one day.
Now you might say: wait, this sounds somehow like the QT project. Yes, since I have enough of the QT bugs (especially related to android) and my thousands of hours related to QT development i know that for me QT is not an option anymore. I would not take on myself that kind of work of developing a cross platform c++ framework if I had an alternative, Sadly there is no alternative in the long run. I write my own framework, because in the long run it's less work than relying on 3rd parties like qt. I even don't have any plans of publishing anything, I do all this for my own needs. And KDE was thrown back exactly because of their QT dependency. They still didn't realize that they have to give up any QT dependency. This would cost them for the moment some effort, but save them later a lot more of time and effort in compensation.

[Nils]

I'm working on Wayland support in Supertuxkart and for me it's much more comfortable to work than X11. And compare CIrrDeviceLinux.cpp is 3170 lines of code while CIrrDeviceWayland.cpp is 1413. The only "uncomfortable" thing is that I have to draw decorations myself and I have no idea why I should care about it when I'm developing a game. Actually I don't want to do it, because it will be ugly :-P

And if you use the C++ bindings, it will be even less lines:

https://github.com/NilsBrause/waylandpp

Kodi uses them for their Wayland support.

[oiaohm]

Saying that Wayland is a protcol and does not have to be implemented in C, this sadly is not quite true. At least you have to link against the c library libwayland-client.
This was at the beginning also my hope, to start just by the protocol and write everything in c++, I even did that for the client part, till I had to notice that you are forced into the dependency of libwayland-client if you want vulkan to work.

Vulkan is also coded in C so if you code in C++ only now you don't have opengl or vulkan libraries.

This is where you have gone complete wrong the reference implementation is done in C there need to be a C version like it or not because too much of the graphic subsystem is pure C. Attempting to put C++ in there does not fly.

https://github.com/NilsBrause/waylandpp

This is a pure C++ implementation. So once you are in your code you can remain in C++ unlike vulkan where the Vulkan-hpp is a pure wrapper over the C implementation.

Basically if someone puts the C behind a curtain where you can no longer see it you have been happy. Also I bet you did not notice using xlib from vulkan when you are using xcb because vulkan standard mandates it supports both so most drivers pull in both.

So you were using vulkan, xcb and xlib unless you custom build vulkan dropping xlib requirement.

Global functions/variables lets to get the evil. xcb, xlib hides the global information in your environmental var settings that is not particularly good performing. Windows, OS X, Android and Wayland hide the information in global functions/variables. Why do you need this global information in the first place. Simple opengl, egl, vulkan the evil bits of work don't internally remember stuff like what screen they are on yet in places in code just straight up ask questions to the graphical system expecting answers.

So opengl, egl, vulkan get out of having to have that stuff by pushing to back to the host graphical environment to cope with and they mandate using C.

If all you have done is work on top of xcb/xlib you are clueless. You missed where xcb and win32 buries it bodies. You are upset because with wayland you can see where they are put in graves.

So having a pure C++ basically equals not having vulkan or any other accelerated open specification graphical system.

[Nils]

https://github.com/NilsBrause/waylandpp

This is a pure C++ implementation.

Not exactly. The core Wayland functionality is just the C library wrapped in C++ classes (proxy, display, etc.). Only the protocol classes are generated pure C++ code. This enables you to use the Wayland C++ bindings with any protocol XML, while benefiting from the stable features of the Wayland C library.

So having a pure C++ basically equals not having vulkan or any other accelerated open specification graphical system.

That depends on the library. The Wayland C++ bindings can be used with OpenGL. (I have not yet tested Vulkan.)

[oiaohm]

That depends on the library. The Wayland C++ bindings can be used with OpenGL. (I have not yet tested Vulkan.)

When I said pure C++ is that you will find that the opengl backend will go back to a C interface to-do stuff. So binding in C libraries and headers of the graphic environment has to happen because all opengl library itself is C.

Vulkan header file wants to import the wayland-client.h header file same way it include xcb, xlib and windows and other platform headers. So its just a reality since its implemented in C you have to put up with C parts being pulled in.