Announcement

Collapse
No announcement yet.

LXQt Desktop Now "100%" Ready For Wayland

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

  • LXQt Desktop Now "100%" Ready For Wayland

    Phoronix: LXQt Desktop Now "100%" Ready For Wayland

    The lightweight LXQt desktop environment is fully ready to take on the Wayland world...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    What are they using as window manager, labwc? Or can one choose? Anyway, big milestone. Possible using the wlroots layer-shell protocol.

    Comment


    • #3
      May they get dark mode right someday.

      Comment


      • #4
        Originally posted by Gusar View Post
        What are they using as window manager, labwc? Or can one choose? Anyway, big milestone. Possible using the wlroots layer-shell protocol.
        i believe labwc is what is being tested, but distros will be able to choose what WM is being used

        Comment


        • #5
          im excited for a new stable wayland DE release, the only 2 stable linux DEs rn are gnome and plasma (not counting window managers), the rest are in development right now so a new stable wayland DE is sorely needed!

          Comment


          • #6
            Originally posted by hedonist View Post

            i believe labwc is what is being tested, but distros will be able to choose what WM is being used
            Presumably it'll work with any compositor that supports the necessary wlroots protocols? I'd be curious to see if it can be integrated with Sway or Hyprland. A hybrid tiling desktop is something I've always wanted. My ideal desktop would be Plasma Shell on-top of a Sway or Hyprland core but KDE uses too many proprietary protocols. I don't even think something like KRunner can even run properly on other compositors (layer shell could be used for that, but why do that when you can use your own proprietary positioning protocol instead?).

            Comment


            • #7
              Originally posted by ahrs View Post

              I don't even think something like KRunner can even run properly on other compositors (layer shell could be used for that, but why do that when you can use your own proprietary positioning protocol instead?).
              KRunner runs fine in Hyprland. I used this command to activate/deactivate krunner with a keybind: "qdbus org.kde.krunner /App org.kde.krunner.App.toggleDisplay"

              Comment


              • #8
                I've found my light weight Wayland DE

                Comment


                • #9
                  I am not a Wayland hater, actually vice versa - I am one of those who jumped to the Wayl​​​​and as soon as distros started to ship it, but it doesn't work for me. By the nature of my work I have to share my screen entirely or some part of my screen or only a window, but Wayland doesn't support this out of the box after all these years.
                  JetBrains IDEs are getting blurry with fractional scaling on Wayland, games don't work with Wayland + Nvidia, and other tens of bugs related to Wayland + Nvidia. And it's not just me, all my coworkers and friends are having the same issues.
                  I do not understand how Wayland is ready to be shipped by default by distros.
                  Last edited by uscracks94; 09 March 2024, 09:51 AM.

                  Comment


                  • #10
                    Originally posted by ahrs View Post
                    I don't even think something like KRunner can even run properly on other compositors (layer shell could be used for that, but why do that when you can use your own proprietary positioning protocol instead?).
                    Given that KDE is at the forefront of Wayland support it is entirely possible that layer shell didn't exist yet at the time when KRunner needed it.

                    Now that it does might lead to future versions of KRunner having support for it.

                    KDE developers are very pragmatic and know to switch custom to shared solutions when they become viable, e.g. DCOP -> D-Bus

                    Comment

                    Working...
                    X