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

  • #11
    Originally posted by dreich View Post

    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.
    Exactly! Like I was saying, we need an improvement and successor to X11. Wayland is just the same old (albeit less featureful) crud all over again.

    Comment


    • #12
      Originally posted by kpedersen View Post
      Like I was saying, we need an improvement and successor to X11.
      Yep, that's what Wayland is; a chronological successor and technological improvement to X11. You don't like it but ... there's nothing you can do about it.

      Comment


      • #13
        Originally posted by birdie View Post
        So, another WayLand compositor without a taskbar? Who uses this crap other than their own developers?
        Originally posted by kpedersen View Post
        ...now we basically rely on a single guys hobby project? Something doesn't seem quite right.
        Originally posted by acobar View Post
        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...
        Couldn't agree more. Somebody bring Linux Hater blog back to life, not much changed regarding usability/responsivity/fluidity/latency/unity/elegance of GNU/Linux on desktops in last 10 years. Linux sucks on desktops as much as ever. Wayland is dead.

        Maybe if Hikari came with cute mascot and anime wallpaper maybe I would use, I would definitely use it.

        Comment


        • #14
          Originally posted by birdie View Post

          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.
          Now you've got me sounding cynical too :P. Yes, it took a the success of a hobby project (wlroots) built due to the fact that another hobby project (wlc) was insufficient for the original project (sway) to convince enough stakeholders (larger organizations/groups like Gnome, KDE, Wayland, Canonical) and other developers not only that interoperable standards for desktop components should exist, but how to design them rationally and got enough buy-in that they have become at least de-facto standards when the original statements were always that everything had to be internal to the compositor like Gnome or use compositor-specific communication methods.

          That far-too-long sentence aside, it still seems to be a great graphics protocol, but incomplete without extensions (as it was intended to be in order to fit other incompatible use-cases) and we've finally got something of a wayland community rather than a set of silos led by the biggest powers in desktop Linux. I'm pretty sure libweston is only used in commercial products because I can't find any compositor beyond weston itself that actually still uses it -- they all moved to wlroots. I wish it was 12 years ago too, but it seems like now we really start the countdown for when wayland by default seems more like a comfortable upgrade rather than tinkering, masochism, or limited needs.

          Comment


          • #15
            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 ).
            Cool. That's nice to know. I've been curious when I'd be able to treat a Wayland compositor like Fluxbox and now it looks like it won't be too far away with Wayfire and mate-panel.

            Comment


            • #16
              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?
              As it is, I don't have any use for a taskbar. It's good for simple window management, but if there are more than 8 large, overlapping windows floating all over the screen...nope, nope nope. Taskbars only make management more troublesome since I may have multiple windows of the same application open, and having the taskbar report those windows as App A; App A (2), App A (3) isn't helping me at all. I already use gnome-shell as-is (without the taskbar) and Plasma without the activity manager in the panel simply because of this.

              I would much rather have some kind of mechanism to tile all the open windows into clickable thumbnails like what Gnome and Plasma offer when there is a need to switch between various windows to get things done. This is the one missing feature from Weston that prevents me from using it as a daily desktop interface. Which is a real pity because Weston actually works (mostly) with Firefox on Wayland and Ozone Chromium with the Wayland option, both of which still do not run on Debian 10's bundled version of Plasma Wayland.

              Comment


              • #17
                Originally posted by birdie View Post

                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.
                I think this illustrates a fundamental misunderstanding about Wayland that many people around here have. Wayland was purposefully designed to be a minimal graphics rendering protocol that can be extended as use cases occur that implementations desire. A taskbar (something I have no use for) is part of a certain desktop paradigm, and so it falls to those implementing compositors to implement it, and if the Wayland protocol requires an extension to facilitate that, then it can be added. Similarly, remote display over a network was not designed in, because it can be added later as implementers require. People get exercised because they think that their personal (often faddish) conception of a desktop is the only obvious and true thing that that should have been explicitly designed for to start with. There are other use cases, such as IVI, kiosks, fanciful things like mapping your windows onto rotating klein bottles (Where are your cartesian coordinates now?), tiling vs layered windows, etc. Not trying to make design assumptions from the beginning was because of the lessons learned from X11-- probably very few people here will eg. know what applications using the Athena widgets look like and would be *horrified*, but that uses cutting edge assumptions designed into X11, like rendering primitives to draw circles and rectangles, etc.

                Also, it helps to realize that X11 took decades to add the features people require to run a modern desktop, and that the window managers and compositors people have become used to would be impossible for most of X11s life. Wayland and the compositors using it will continue to develop and add desired functionality over time, and as usual the utilities and libraries will become more comprehensive. Now that major desktops and vendors are starting to offer things that more end users encounter, this process will accelerate.

                Comment


                • #18
                  Originally posted by set135 View Post

                  I think this illustrates a fundamental misunderstanding about Wayland that many people around here have. Wayland was purposefully designed to be a minimal graphics rendering protocol that can be extended as use cases occur that implementations desire. A taskbar (something I have no use for) is part of a certain desktop paradigm, and so it falls to those implementing compositors to implement it, and if the Wayland protocol requires an extension to facilitate that, then it can be added. Similarly, remote display over a network was not designed in, because it can be added later as implementers require. People get exercised because they think that their personal (often faddish) conception of a desktop is the only obvious and true thing that that should have been explicitly designed for to start with. There are other use cases, such as IVI, kiosks, fanciful things like mapping your windows onto rotating klein bottles (Where are your cartesian coordinates now?), tiling vs layered windows, etc. Not trying to make design assumptions from the beginning was because of the lessons learned from X11-- probably very few people here will eg. know what applications using the Athena widgets look like and would be *horrified*, but that uses cutting edge assumptions designed into X11, like rendering primitives to draw circles and rectangles, etc.

                  Also, it helps to realize that X11 took decades to add the features people require to run a modern desktop, and that the window managers and compositors people have become used to would be impossible for most of X11s life. Wayland and the compositors using it will continue to develop and add desired functionality over time, and as usual the utilities and libraries will become more comprehensive. Now that major desktops and vendors are starting to offer things that more end users encounter, this process will accelerate.
                  You're not wrong, but it looks like you're purposely missing the point. Active (not just in terms of users, but development as well) communities of (often lightweight) modular desktop components were spurned by the notion that interoperability of components between wayland compositors was expected not to exist. Now we have layer-shell and wlr-foreign-toplevel-management among other now common extensions to the wayland protocol that are now considered normal for compositors targeting desktop use-cases to implement. Neither specify that you need a taskbar, but do allow one to exist while remaining flexible enough to allow for entirely separate use-cases and desktop paradigms still available as modular components that individuals or groups not directly associated with a particular compositor can write. Other examples using layer-shell include notifications and background images. You can also now decouple output management -- the arrangement of your displays -- to an application outside of your compositor's codebase by implementing the requisite protocol. The list goes on.

                  Comment


                  • #19
                    Originally posted by hax0r View Post





                    Couldn't agree more. Somebody bring Linux Hater blog back to life, not much changed regarding usability/responsivity/fluidity/latency/unity/elegance of GNU/Linux on desktops in last 10 years. Linux sucks on desktops as much as ever. Wayland is dead.

                    Maybe if Hikari came with cute mascot and anime wallpaper maybe I would use, I would definitely use it.
                    Linux is superior in performance, usability, responsibility, latency, fluidity and far more elegant. Your brain is dead stupid prick. It took X nearly thirty years to become usable on desktop and it's still not complete. You should be praising Wayland on your knees. Windows only lives thanks to applications. In every other case it's an utter mess. Slow, unresponsive, chocking and insecure.

                    Comment


                    • #20
                      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?
                      The point of these compositors is that you build your own working environment out of spare parts of which the compositor is but one. The MATE panel can probably be used with this, or you can use something simpler like Waybar or Swaybar.

                      I don't use a taskbar as they aren't really useful when you're using a tiling window manager. But they do exist.

                      Comment

                      Working...
                      X