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

  • birdie
    replied
    Originally posted by mdedetrich View Post

    This is kind of half true. X11 is only full of spaghetti hacks right now because its 30+ years old, and back then graphics technology was very different to what it is now. In the past the composition/desktop stack was very different to what it is now (both from a technology level and what people expected). However in the past 5-7 years, there hasn't really been any big changes as is evidenced by Microsofts WDDM which was introduced when vista came around and hasn't seen serious changes since then.
    I used Linux in the late 90s, so not much spaghetti code as I don't recall any differences from what I have now - and, no, I don't use compositing because I find it distacting and it also adds latency.

    Leave a comment:


  • mdedetrich
    replied
    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.
    This is kind of half true. X11 is only full of spaghetti hacks right now because its 30+ years old, and back then graphics technology was very different to what it is now. In the past the composition/desktop stack was very different to what it is now (both from a technology level and what people expected). However in the past 5-7 years, there hasn't really been any big changes as is evidenced by Microsofts WDDM which was introduced when vista came around and hasn't seen serious changes since then.

    Leave a comment:


  • royce
    replied
    Originally posted by kpedersen View Post
    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.
    Actually wlroots has a pretty sizeable amount of developers contributing code. And you also have mutter, kwin and weston for alternative wayland implementations.

    Leave a comment:


  • royce
    replied
    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.

    Leave a comment:


  • Volta
    replied
    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.

    Leave a comment:


  • BwackNinja
    replied
    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.

    Leave a comment:


  • set135
    replied
    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.

    Leave a comment:


  • Sonadow
    replied
    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.

    Leave a comment:


  • skeevy420
    replied
    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.

    Leave a comment:


  • BwackNinja
    replied
    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.

    Leave a comment:

Working...
X