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

  • patrick1946
    replied
    Originally posted by ehopperdietzel View Post
    Creating a Wayland compositor is a challenging task, and one of the motivations behind Louvre was to simplify this process, enabling more individuals to contribute and innovate in this domain. While I could have contributed to the development of wlroots, I was a novice at that time and struggled to find comprehensive documentation on wlroots. Consequently, I decided to start Louvre from scratch to gain a deeper understanding of Wayland and its inner workings.
    Hello

    I looked a little bit into your code and was surprised to see that you are still using raw pointer for ownership. And even std::list and Pimple.
    The whole framework reminded me a little bit to Qt. But that was designed 20 years ago and today people would use different pattern.

    Is there a reason that you chose this old pattern for a new C++ library?

    Leave a comment:


  • geearf
    replied
    Originally posted by Kemosabe View Post

    Because it starts with C too?
    Nope.

    Leave a comment:


  • Kemosabe
    replied
    Originally posted by geearf View Post
    Isn't that the same for C++?
    Because it starts with C too?
    There is no content in your comment I could respond to.

    Leave a comment:


  • avis
    replied
    I love Wayland!

    Leave a comment:


  • trek
    replied
    Originally posted by ehopperdietzel View Post
    Hello, I am the developer of Louvre, and I would like to express my gratitude to Michael Larabel for sharing information about the project.
    Good work! It seems a very nice project.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by darkonix View Post

    I have several different overlapping and/or contradictory opinions about that ;-)
    LOL...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by user1 View Post

    Just curious, what do you not like about them?
    Mutter is off the table right away due to having to deal with typical gnome bullshit. you can actually work with KDE devs so that's a lot more promising, but in the end, kwin is still a massive, old project and because of that it's still hard to hack on. ofc thats not to say you can't do it, you absolutely can, and the code isn't a bad quality, its still just a bloody lot to deal with.

    in the end, doing something from scratch the way you know how to, and in a way you are comfortable with, is much better then trying to shove shit code into a pre-existing project.

    Leave a comment:


  • Fanboy80
    replied
    I compiled that project, but when I start louvre-weston-clone nothing happens, no messages and no output. I thought that file was a reference implementation, what am I missing here?

    Leave a comment:


  • MadCatX
    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.
    The key difference here was that ESD, aRts, ORBit and DCOP were born out of pure necessity, didn't aim to provide any particularly sophisticated functionality and at least the KDE-umbrella projects had numerous technical issues. Giving them up for something common and better maintained was welcomed by everyone. Furthermore, neither IPC nor audio handling is specific for graphical desktop environments.

    On the other hand, window management is specific to DEs and it is one of the most important parts of use experience. I'd argue that the one major difference between GNOME and Plasma is how they manage windows and workspaces. Major DEs need to develop their own WMs because they are key to the user experience they provide. In the Wayland world, the WM is also the compositor, so swapping out all the guts for something common and implementing all of custom feature on top of it would be a massive pile of work with dubious benefits.

    Leave a comment:


  • 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:

Working...
X