[Not a bug] Discussion about louvre HOT 12 CLOSED

I just want you to know, that this looks really cool and that even though there's some toxic people you seem to be doing great works.
I'm always happy to see an expansion of the ecosystem and have access to more alternatives.

from louvre.

Thank you, you are very kind :). I'm realizing that a significant portion of the people who complain don't fully know what they're talking about, but it's still interesting to know their opinions. Anyway, as a friend of mine said, no matter what you do, there will always be people who get upset about it, hahaha.

from louvre.

@birdie-github I believe what's lacking is for Wayland experts, input and graphics driver developers, and toolkit developers to sit in the same room, engage in discussions, and design protocols for handling each functionality. They should take all the necessary time to reach an agreement that satisfies everyone.

from louvre.

Hello, I understand that people might be frustrated that, as of today, not all the functionalities we had with X11 are yet available with Wayland. However, we are getting closer each day to achieving that.

Regarding all the fuss about fragmentation and such, it is true that Wayland's flexibility allows for a myriad of ways and protocols to address similar problems. However, this, on one hand, is positive because it leads to the emergence of good ideas that eventually become predominant. The issue is not only with Wayland itself but also with the various Linux APIs and drivers that control input and graphics, strongly influencing the functionalities a compositor can offer.

In my case, though, I am not redesigning the entire concept of Wayland or proposing different ways of doing things. My goal is simply to provide a more straightforward API for developing compositors, with the idea that it should be more user-friendly for anyone, without requiring you to be a Wayland and Linux API guru to bring your ideas to life. I also believe that Louvre can serve as a valuable educational tool.

I don't plan to include all protocols, only mainly those that have already been standardized or will be. That being said, I find it beneficial that alternatives exist, just like Qt or GTK for building applications. Perhaps you prefer one over the other, but both essentially allow you to do the same things.

from louvre.

Regarding all the fuss about fragmentation and such, it is true that Wayland's flexibility allows for a myriad of ways and protocols to address similar problems.

Flexibility leading to a duplication of effort for implementing and debugging features over and over. Do we really need 10+ ways to output graphics in Linux when with Xorg we has just one?

The issue is not only with Wayland itself but also with the various Linux APIs and drivers that control input and graphics, strongly influencing the functionalities a compositor can offer.

Yeah, but that sounds like Wayland is simply missing some crucial features/APIs.

In my case, though, I am not redesigning the entire concept of Wayland or proposing different ways of doing things.

I'm not asking for that either.

I find it beneficial that alternatives exist, just like Qt or GTK for building applications.

Qt and GTK have a lot more differences than being just "a graphics toolkit". Qt is C++ and it's a library for writing rich applications. GTK is C and it's a graphics toolkit only.

I'm glad you've admitted the issue exists, too bad I don't see how multiple Wayland implementations could benefit anyone. The protocol has existed for over 15 years and we have the only fully functional relatively bug free implementation which is Gnome/Mutter. KDE is still struggling. Other implementations are just laughable in terms of features.

It looks completely bizarre and crazy that the desktop features you get with Wayland depend on the compositor you log in. That's not the case with any OS that I've ever worked with. Not a single successful OS offers multiple graphics servers either. Linux had several X11 implementations but there was always XFree86/Xorg and the rest were for very specific use cases. You didn't have to Google to confirm that e.g. IceWM supports HD displays.

from louvre.

We already have wlroots. Why do we need another one that is identical?

from louvre.

@binex-dsk They are not the same. The API and design are quite different. Additionally, the internal architecture allows for a stable high FPS rate, which is quite noticeable, for example when dragging windows.

from louvre.

The API and design are quite different

For what purpose? I honestly don't see a need to fragment the Wayland world. wlroots exists, is mature and gradually being supported even by KDE.

allows for a stable high FPS rate

I have no issues with FPS either on sway, even on a computer the same age as me... elaborate?

from louvre.

For what purpose? I honestly don't see a need to fragment the Wayland world. wlroots exists, is mature and gradually being supported even by KDE.

I created it with people who know nothing or little about Wayland in mind. The idea is to provide a default implementation of everything that can gradually be overwritten. From my perspective, this approach offers a much more pleasant and interactive learning experience, potentially reducing development time significantly. Learning to implement each protocol and manage graphics and input takes a considerable amount of time. While wlroots simplifies several aspects, it still leaves a lot in the hands of the developer. In my case, after a year of working on this project and gaining all the experience, only now would I be capable of creating a compositor with wlroots.

I have no issues with FPS either on sway, even on a computer the same age as me... elaborate?

Perhaps on low-resolution screens, it's not noticeable. But I believe that the majority of screens nowadays are HDPI, including mine, and at least on my laptop, the FPS drop of some compositors is quite noticeable.

from louvre.

Concerning fragmentation, when creating a compositor with Louvre or wlroots, you likely use the same protocols (although there are still many missing in Louvre). Consequently, applications will function regardless of whether you choose one or the other. Thus, I fail to comprehend why there is such significant emphasis on the issue of fragmentation.

from louvre.

Thus, I fail to comprehend why there is such significant emphasis on the issue of fragmentation.

These are my initial thoughts, I am skeptical at every new "standard" or library that gets introduced for new protocols and software. Glad to see you thought of this issue.

To nag a little more, do wlroots-reliant applications work with Louvre or do they instead require to be ported?

from louvre.

There are plenty of protocols; you can see them here: https://wayland.app/protocols/.

However, some are already quite standard and are used by practically all compositors and toolkits like Qt, GTK, etc. The most basic ones are Wayland and XDG Shell. With these protocols alone, you can create a compositor that displays windows that can be maximized, dragged, and handles keyboard and mouse events, etc.

Now, there are many others that are not essential, such as Linux-DMA-Buf, which provides an efficient way for clients to share their graphics buffers with the compositor. Apps that support it simply use it, and if it's not available, they use Wayland's shared memory or some other method.

Then there are many non-essential protocols that can provide some additional functionality, but if they are not present, the apps still work. Therefore, yes, it's not necessary to port your apps for them to function. However, some specific non-essential features may be in one compositor and not in another. It's these protocols where we still need to come to an agreement, but progress is being made.

In Louvre, I plan to integrate only protocols that are already considered standard to avoid implementing something that might not be used in the future.

from louvre.