Announcement

Collapse
No announcement yet.

Wayland 1.19 Alpha Released

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

  • trasz
    replied
    Originally posted by curfew View Post

    One major issue is also platform-independence. When each and every window manager has to re-implement abstract crap on their own, they will use whatever is convenient. Right now each and every Wayland compositor is strictly tied to Linux, blocking modern desktops from the BSDs in a brutal way.

    If we had a single centralized implementation, it would be trivial to make all DEs platform-independent by porting this single (albeit major) piece of software to FreeBSD or NetBSD or other FOSS operating systems. Since porting code designed for Linux-specific libraries isn't an easy task, you can only imagine the burden on the BSD devs to making even a single desktop environment run smoothly on BSD, and the tears when they have to start all over again to make it happen with another DE again.
    Erm... what? Are you saying the official FreeBSD Sway or Wayfire ports/packages don't exist?

    Leave a comment:


  • curfew
    replied
    Originally posted by nomadewolf View Post

    Maybe it's something for Wayland 2.0?...
    Wayland, also titled as "X12", is succeeding a protocol conceived in 1987. So good luck with your wait for the next incarnation.

    Leave a comment:


  • curfew
    replied
    Originally posted by set135 View Post

    Well, there are a few libraries. libweston and wlroots being probably the most prominent. wlroots lists dozens of projects using it, so the claim that every compositor has its own implementation seems incorrect. What is probably more correct is that the two majors of the linux desktop have mostly gone their own way implementing wayland because they have a large legacy code base.
    Libraries are useless and do not really solve the issue of fragmentation and lacking feature-parity between DEs. Canonical's Mir is the only viable solution that is also something else than a a half-baked, opinionated prototype.

    One major issue is also platform-independence. When each and every window manager has to re-implement abstract crap on their own, they will use whatever is convenient. Right now each and every Wayland compositor is strictly tied to Linux, blocking modern desktops from the BSDs in a brutal way.

    If we had a single centralized implementation, it would be trivial to make all DEs platform-independent by porting this single (albeit major) piece of software to FreeBSD or NetBSD or other FOSS operating systems. Since porting code designed for Linux-specific libraries isn't an easy task, you can only imagine the burden on the BSD devs to making even a single desktop environment run smoothly on BSD, and the tears when they have to start all over again to make it happen with another DE again.
    Last edited by curfew; 22 December 2020, 08:07 AM.

    Leave a comment:


  • nomadewolf
    replied
    Originally posted by zxy_thf View Post
    This could be a good move, but I'm afraid it's too late now.
    If something like libwayland-compositor was proposed and developed 5 years ago, this could end up inside different compositors.
    But nowadays since every compositor has its own implementation, this library is pointless. New developers may prefer to fork an existing project and start from there.
    Maybe it's something for Wayland 2.0?...

    Leave a comment:


  • rastersoft
    replied
    Originally posted by timofonic View Post
    I think Wayland should adopt the Vulkan approach, not the current one.
    Can you expand this? I don't know what is "the Vulkan approach".

    Leave a comment:


  • set135
    replied
    Originally posted by zxy_thf View Post
    This could be a good move, but I'm afraid it's too late now.
    If something like libwayland-compositor was proposed and developed 5 years ago, this could end up inside different compositors.
    But nowadays since every compositor has its own implementation, this library is pointless. New developers may prefer to fork an existing project and start from there.
    Well, there are a few libraries. libweston and wlroots being probably the most prominent. wlroots lists dozens of projects using it, so the claim that every compositor has its own implementation seems incorrect. What is probably more correct is that the two majors of the linux desktop have mostly gone their own way implementing wayland because they have a large legacy code base.

    Leave a comment:


  • zxy_thf
    replied
    Originally posted by furtadopires View Post

    Agreed

    I also said this in the last wayland post.
    This could be a good move, but I'm afraid it's too late now.
    If something like libwayland-compositor was proposed and developed 5 years ago, this could end up inside different compositors.
    But nowadays since every compositor has its own implementation, this library is pointless. New developers may prefer to fork an existing project and start from there.

    Leave a comment:


  • furtadopires
    replied
    Originally posted by timofonic View Post
    I think Wayland should adopt the Vulkan approach, not the current one.
    Agreed

    I also said this in the last wayland post.

    Leave a comment:


  • timofonic
    replied
    I think Wayland should adopt the Vulkan approach, not the current one.

    Leave a comment:


  • jukkan
    replied
    Is drag-and-drop working now? Or is that planned for an upcoming release?

    Leave a comment:

Working...
X