Announcement

Collapse
No announcement yet.

Louvre Is A New C++ Library Helping To Build Wayland Compositors

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • varikonniemi
    replied
    Originally posted by jacob View Post

    Never say never. GNOME and KDE were both heavily invested in their ORBit and DCOP IPC systems and happily threw them out when DBUS came along. They had their own audio servers and moved to Pulse Audio (and now PipeWire). They had their own session management logic and readily switched to systemd (at least GNOME did, not sure about KDE). So if there was a Wayland display manager foundation that does what they need, I don't see why they would eventually use it if ultimately it allows them to reduce their development effort.
    especially KDE which is written in C++ could sync up well with this new compositor, while gnome might better sync with wlroots.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by user1 View Post

    That's not a good analogy. Minix was an OS for educational purposes, so not something for general usage. When it comes to Wayland libraries, I see wlroots as something that at least reduces the fragmentation of the Wayland ecosystem, since there is no reference display server implementation like in the case of X.org. While Gnome and KDE already have their own Wayland display server implementation, I think it's good if everything else will target wlroots in order to reduce fragmentation. And this is an attempt to only make it worse. Because even if they claim to have some performance benefits, it doesn't seem like their main goal of easing the development of Wayland compositors is any different to that of wlroots.

    And this is what bothers me about open source in general. On one hand, you have so many complains about developer burnout, lack of resources and lack of compensation, but on the other hand, some developers find resources to fork stuff, or reinvent the wheel only for marginal benefit.
    I think the bigger explanation behind this chaotic mess is that when Wayland was initially released it was just a protocol with a reference implementation (Weston). What they should have done is also released a wl-roots like library from the beginning to make it easier for compositors to adopt/try out/prototype Wayland, even if a hypothetical wl-roots like library wouldn't be usable by some compositors at least the developers would have some idea on what to expect.

    Instead what we got was a protocol, which for anyone that has any experience in software development knows what you can actually ascertain from a protocol (aside from some properties) is very little, and the Weston (the reference implementation) was next to useless for this specific usecase. This state of affairs meant that for the large part of a decade, Wayland got almost no real world use (no one really took it that seriously) and to the point of this thread, we got this annoying fragmentation where every compositor ended up developing their own integrations into Wayland.

    Even with wl-roots, the DE/compositors that actually use it are a drop in the ocean compared to the jugernauts (KDE/Gnome/Mir etc etc)

    Leave a comment:


  • geearf
    replied

    Originally posted by mmstick View Post

    Probably because they wanted to write a Wayland compositor natively in C++ rather than C. Same as why Smithay exists as a Wayland compositor library for Rust.
    Yeah that's probably that.​

    Originally posted by Kemosabe View Post

    One of the reasons may be: C is simply not suitable for the 21st century anymore.
    Isn't that the same for C++?


    Originally posted by ehansin View Post

    Well, neither are written in Rust, so there is that problem (relax, relax, just making a funny!)

    But for real, I sort of see two somewhat contradictory, yet both valid takes in the whole open source thing:

    * Too much duplicated effort across similar projects trying to scratch the same itch.
    * People exploring different pathways to solve similar problems can come across new ideas that might not reveal themselves if there was not this duplicated effort.

    I don't think there is a singular one right answer to the above, both are valid takes. I suppose it is like a lot of things in life, answer sort of falls somewhere in the middle or can be both at the same time. When does energy and efforts become so dispersed to the point of absurdity, and when are efforts so concentrated that it leads to group-think and tunnel vision?
    Yeah I feel you, but there's already plenty of non-wl-root compositors, not sure we needed more; of course, maybe those compositors will eventually migrate to this because it could end up better or more appropriate language or something else.

    Thanks!

    Leave a comment:


  • darkonix
    replied
    Originally posted by zexelon View Post
    Lets be honest... fragmentation IS the number one product of the Linux ecosystem.
    I have several different overlapping and/or contradictory opinions about that ;-)

    Leave a comment:


  • juxuanu
    replied
    Originally posted by Morty View Post

    Qt...
    That does much more than what I asked for.

    Leave a comment:


  • Morty
    replied
    Originally posted by juxuanu View Post
    Is there a library to simplify creating a wayland *client*? All the fuss seems to be around compositors.
    Qt...

    Leave a comment:


  • kpedersen
    replied
    Originally posted by Brittle2 View Post

    i don't like the standardize on wlroots, they have a lot of extensions that are outside of the official wayland protocol
    I get that. It seems to act like a polyfill whilst Wayland matures and people start to notice all the stuff they actually need.

    Leave a comment:


  • Brittle2
    replied
    Originally posted by kpedersen View Post

    By the time they do standardize; wlroots probably won't even exist or be used anymore. Plus things like Weston and Sway will be seen as the old TWM of Wayland compositors.
    i don't like the standardize on wlroots, they have a lot of extensions that are outside of the official wayland protocol, it's like xorg, that implement so much things outside of the x11 protocol, maybe with 2 or 3 big compositors this can be fixed, so devs target the official extensions and it work on everything

    Leave a comment:


  • Brittle2
    replied
    Originally posted by uid313 View Post
    But can it do gamma correction, Night Light, HDR, ICC color profiles, and v-sync?
    chill out, it's a new library

    Leave a comment:


  • Kemosabe
    replied
    Originally posted by JMB9 View Post

    Well, so Linux is written in ... ups, C ... is there any OS currently being technically superior to Linux?
    And all the effort concerning Rust is done to get a few drivers wirtten by ... a larger group of people ...
    which lead to usage of Java (and formerly BASIC) ...

    So looking at currently used code in important cases we see basically C, Cobol, Fortran ...
    and after a gap a huge croud of programming languages (of more than 2000 if countable at all;
    see "The Mess We're In" by Joe Armstrong: https://www.youtube.com/watch?v=lKXe3HUG2l4).
    But maybe someone could shed some light about programming language usage who really knows better.
    And a lot of code is used behind closed doors ...

    Personally, I like having C++ libraries for all purposes - as after my taste C++ would (after C and Fortran
    used in former times) be most attractive (games, GUIs, ...) - while Rust is really in its infancy and
    moving quite fast. But Linux may be a reason that it will get ripe sooner than later ... we will see.

    I think that every technical task without at least 2 alternatives is a problem.
    Would anyone be happy if only GNOME would exits? Choice is important for experts.
    Only beginner are happy to not have any choice or not having plenty of options - as
    experts have to tailor everything to their needs to work in the most effective way
    possible (i.e. {nearly} no mouse or touch screen).
    :facepalm:

    Leave a comment:

Working...
X