Announcement

Collapse
No announcement yet.

Hikari 2.2 Wayland Compositor Adds Support For WayVNC, Other Features

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

  • Hikari 2.2 Wayland Compositor Adds Support For WayVNC, Other Features

    Phoronix: Hikari 2.2 Wayland Compositor Adds Support For WayVNC, Other Features

    Hikari, the FreeBSD-focused Wayland compositor that also works on Linux systems, is out with a new feature release...

    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
    So, another WayLand compositor without a taskbar? Who uses this crap other than their own developers? Why is it so difficult to have this feature implemented in Wayland when it's available in absolute most X.org DEs/Window Managers/whatever?

    Comment


    • #3
      I have nothing against wlroots but I look forward to seeing more compositors that aren't dependent on this single (potentially unstable in terms of API) dependency.

      Back in the day we had at least 10 large corporations developing and testing things like libX11 and yet now we basically rely on a single guys hobby project? Something doesn't seem quite right.

      Comment


      • #4
        Originally posted by kpedersen View Post
        I have nothing against wlroots but I look forward to seeing more compositors that aren't dependent on this single (potentially unstable in terms of API) dependency.

        Back in the day we had at least 10 large corporations developing and testing things like libX11 and yet now we basically rely on a single guys hobby project? Something doesn't seem quite right.
        Wayland as a whole doesn't seem right considering it has just one fully functional implementation in a form of Gnome. And that's after full 12 years since its inception. Smaller window managers and DEs don't even consider supporting it, e.g. IceWM, JWM, OpenBox, etc.

        Comment


        • #5
          Originally posted by kpedersen View Post
          Back in the day we had at least 10 large corporations developing and testing things like libX11
          And what a great job they've done (especially the testing part) ! Couple of days ago everyone had to go patch crap like libX11 and their never ending cavalcade of CVEs.

          Originally posted by kpedersen View Post
          and yet now we basically rely on a single guys hobby project? Something doesn't seem quite right.
          Well that's because a single guy in his spare time can do a far better job that those 10 large corporations combined.
          Last edited by dreich; 08 September 2020, 11:01 AM.

          Comment


          • #6
            Originally posted by kpedersen View Post
            I have nothing against wlroots but I look forward to seeing more compositors that aren't dependent on this single (potentially unstable in terms of API) dependency.

            Back in the day we had at least 10 large corporations developing and testing things like libX11 and yet now we basically rely on a single guys hobby project? Something doesn't seem quite right.
            My main critic toward Wayland was always about how to just specify a protocol is a stupid decision that would generate fragmentation and incompatibilities on the long run because developers still need to address real problems not contemplated on specs. Once you have invested yourself to your particular solution, it is hard to go back. I wish that Gnome, KDE and the other players could address this deficiency and work around a common solution, like a wlroots improved. What is good for io libraries is also good for graphics libraries, a real and almost complete implementation where bugs can be squashed, and improvements and optimizations, landed by as many developers as possible. Cooperation have been the main characteristic of every successful FOSS effort. Unluckily, I guess, that train already departed.

            I'm not even going to start about how crap the current solutions are for network clients using Wayland desktops.

            Comment


            • #7
              Originally posted by dreich View Post
              And what a great job they've done (especially the testing part) ! Couple of days ago everyone had to go patch crap like libX11 and their never ending cavalcade of CVEs.
              I just hope wlroots isn't "too small" to get audited. Do people just assume it doesn't have similar problems?


              Originally posted by dreich View Post
              Well that's because a single guy in his spare time can do a far better job that those 10 large corporations combined.
              In some ways I agree with this (which is why I am concerned the growing corporate influence over Linux will become a problem in the future and evidenced that the BSD projects are thriving). However small guys can sometimes get hit buy a bus. Or worse.... become bored of the project... Or even worse, sell it to Microsoft.

              Putting all eggs in one basket seems an amateur mistake. wlroots needs more forks and more people working on it. I certainly would if I wasn't confident that there will not be sufficient uptake in Wayland vs X11. I actually mean this sincerely; I do only have time to work on one tech and had to make a choice. Hope it was the right one

              Originally posted by acobar View Post

              I'm not even going to start about how crap the current solutions are for network clients using Wayland desktops.
              You may have seen my rants about this already on these forums. The lack of consideration towards a network aware desktop makes the whole Wayland ecosystem look like a bunch of clowns. However I suppose for its use case (hobbyist, consumer, Steam gaming) this isn't a problem :/.
              But yes, this is one of the biggest reasons why I don't feel the uptake will be considerable. Its a shame, we do need a good replacement for X11 and now Wayland is going to be blocking that for the next 10 years until it gets canned and we can finally start progress again (perhaps on a successor like X12).
              Last edited by kpedersen; 08 September 2020, 11:18 AM.

              Comment


              • #8
                Originally posted by birdie View Post
                So, another WayLand compositor without a taskbar? Who uses this crap other than their own developers? Why is it so difficult to have this feature implemented in Wayland when it's available in absolute most X.org DEs/Window Managers/whatever?
                There's already a protocol for that, wlr-foreign-toplevel-management. Hikari doesn't support that (at least yet), but any wayland compositor that supports both that and layer-shell can use a panel like mate-panel. This includes wayfire and sway (which are both built on wlroots), and mir ( https://github.com/MirServer/mir/pull/1684 ).

                Comment


                • #9
                  Originally posted by kpedersen View Post
                  Putting all eggs in one basket seems an amateur mistake.
                  Both X11 and xorg made that perfectly clear a long time ago. There is a price attached to the spaghetti implementation of hacks and terrible design decisions of the past meaning that, if a solution does exist, it doesn't involve X.

                  Comment


                  • #10
                    Originally posted by BwackNinja View Post

                    There's already a protocol for that, wlr-foreign-toplevel-management. Hikari doesn't support that (at least yet), but any wayland compositor that supports both that and layer-shell can use a panel like mate-panel. This includes wayfire and sway (which are both built on wlroots), and mir ( https://github.com/MirServer/mir/pull/1684 ).
                    Are you saying it's taken them 12 years to implement a taskbar (API)? No wonder most people and serious companies do not give a damn about Wayland. Such a wonderful lightweight ... unusable graphics protocol.

                    Comment

                    Working...
                    X