6 ms·

I wish they support Linux wholeheartedly, a lot of toolkits and GUI frameworks do it by half-assing things, mostly because Wayland is difficult to understand.

• Pay08 7mo ago
  Not to mention that there's no clear documentation for this anywhere. A while ago I was attempting to debug some Wayland-specific issues with a graphics library, it turns out the issue was that the little documentation there was, was wrong about what is and isn't nullable.
  • OtomotO 7mo ago
    I found https://wayland.app/protocols/ https://wayland.app/protocols/ very helpful so far. That and studying smithay code.
    • Pay08 7mo ago
      That was the documentation with the incorrect nullability I was referencing.
      • mahkoh 7mo ago
        I doubt there is anything incorrect there. See the note here: https://wayland.freedesktop.org/docs/book/Message_XML.html#allow-nulltrue--false https://wayland.freedesktop.org/docs/book/Message_XML.html#a...
      • kelnos 7mo ago
        wayland.app just HTML-renders the contents of the specification XML files. If a compositor or client is not interpreting nullability the same way wayland.app says it should be interpreted, then that's a bug in the compositor or client.
        • Pay08 7mo ago
          What if no compositor is interpreting it correctly? We tested on Weston, GNOME (this was shortly after it went Wayland-only) and Plasma and the same problems persisted on all 3. In all fairness, the exact functions with wrong nullability might have been different, I don't remember, but the nullability issue itself was persistent on all 3.
    • mroche 7mo ago
      What's needed beyond API docs is a review, refresh, and possible merging of the two Wayland Books by active Wayland contributors. https://wayland.freedesktop.org/docs/book/ https://wayland.freedesktop.org/docs/book/ https://wayland-book.com/ https://wayland-book.com/
  • torginus 6mo ago
    This is what I dislike about a lot of open source projects (not all, but a significant amout of the notable ones) - publicly it's proclaimed that the code's open, and you are free to fix bugs and implement your changes. But when you try to do so, you see there's very little documentation and help out in the open, and by the commit history, you can see there's been like three dozen people who have ever contributed to the project. The rate of code change and the obscurity means the knowledge simply does not build up over time. So it's unclear how to fix an issue you've encountered, or add a feature, and if you've done so, how to get your changes merged.
  • pjc50 6mo ago
    Not that I normally support this kind of thing, but.. how are the AI results in this context? Are they bad due to lack of docs?
• audidude 7mo ago
  In X11 we kept things simple by offering: * Core protocol drawing (lines, rectangles, arcs, the classics) * XRender for compositing and alpha * XShm for shared-memory blits * GLX if you felt like bringing a GPU to a 2D fight * XVideo for overlay video paths * Pixmaps vs Windows, because why have one drawable when you can have two subtly different ones * And of course, indirect rendering over the network if you enjoy latency as a design constraint
  • smackeyacky 7mo ago
    And it worked very well for a remarkably long time. Even over dialup if you were patient. It still seems bizarre that the security flaws couldn’t be addressed, I never understood the Wayland push and I still don’t.
    • UltraSane 7mo ago
      Once applications moved local and GPUs became the rendering path X11's network transparency became pure overhead for 99% of users. Wayland fixes this by making shared-memory buffers the core primitive and remote access a separate concern.
      • cindyllm 7mo ago
        [dead]
      • Underphil 7mo ago
        ...and then you have long time Linux users (like me) who cannot feel any of the benefit of removing that overhead. The only difference I can tell between X and Wayland on my machines is that Wayland doesn't work with some stuff.
        • UltraSane 7mo ago
          I'm pretty sure it simplifies the code a lot.
• shevy-java 7mo ago
  Wayland is a mess. Perhaps https://github.com/X11Libre/xserver https://github.com/X11Libre/xserver can revive the older ecosystem. Almost nobody writes for wayland. About two years ago I tried to switch, then gave up when I realised how many things are missing on wayland. And then I noticed that barely anyone wrote software for wayland. It feels like a corporate advertisement project really. GNOME and KDE push for wayland now.
  • LeFantome 7mo ago
    What does “nobody writes for Wayland” mean? If you write software using GTK, Qt, or FLTK then you are writing Wayland software. The majority of Linux desktops are Wayland at this point. Nobody writes software for them? The Steamdeck uses gamescope which is Wayland. GNOME, COSMIC, Budgie, Niri, and Hyprland are not just Wayland but Wayland only. KDE will be Wayland only soon. Cinnamon is switching to Wayland. XFCE is writing a Wayland compositor. What percentage of Linux desktop users are not using one of the above? 10 at most?
    • deleted 7mo ago
      [deleted]
    • noselasd 7mo ago
      It just means "noone" uses the wayland APIs directly, but instead they leave the wayland complexity to GTK,Qt or FLTK, and they call their app a Qt app, not a Wayland app.
      • simonh 7mo ago
        Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.
        • deleted 7mo ago
          [deleted]
        • 7mo ago
• sandreas 7mo ago
  For everyone interested in Avalonia's Linux / Wayland strategy: https://avaloniaui.net/blog/bringing-wayland-support-to-avalonia https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
  • MikeCodesDotNET 7mo ago
    We’re actively working on Wayland support for Avalonia 12. While we considered dual licensing it, we ultimately decided to keep things simple and make it MIT licensed.
    • zamalek 7mo ago
      > [Article] What works in GNOME might not work in KDE. What works in both might not work in Sway. If you subtract GNOME from the set then things become a lot more sane. "Compositor-specific extensions" are really "everyone besides GNOME extensions." The system tray extension isn't KDE-specific. Sure, window positions might not be available at all (because they don't make sense for a TWM), or a user might not have a system tray bar (or you might be on GNOME). However, if they did have a system tray it would be the StatusNotifierItem protocol. Ideally, these should be handled like other platform features like accelerometers etc.. That may not be possible, either way a lot of them can safely noop. > [Article] For Avalonia, this means "Wayland support" isn't one implementation, it's potentially dozens. We're not just writing a Wayland backend; we're writing a GNOME-Wayland backend, a KDE-Wayland backend, a Sway-Wayland backend, If you're making per-WM backends then you've fundamentally misunderstood how extensions are supposed to work. Other Wayland client libraries do not have a independent backends for KDE, Sway, and GNOME. Maybe quirks would be needed because you're attempting to support an existing UI library - but those should be few and far between. IIRC Avalonia supports Vulkan as a rendering backend? Wayland protocols are the same line of thinking as Vulkan extensions. wlroot and smithay are good examples of what extensions are used in the real world.
      • a_vanderbilt 7mo ago
        My experience was the same while helping to adapt a Steam Deck game for wider Linux support. The issue wasn't Waylandisms, most of those have already by figured out. It was GNOME. Their preferred resolution to issues seems to be dropping support rather than bug fixes, and they go out of their way to adopt implementations that are against the momentum of the wider community. I can get why they make some of their decisions, but things like killing the tray indicator or server side decorations are insane. To be an outlier in name of a greater or grander goal is one thing, then there is whatever GNOME is doing.
• throwaway27448 7mo ago
  Why is Wayland so complicated? I thought half the reason for breaking with X11 was to produce a simpler window server. I was flabbergasted when I realized that there were competing compositors for seemingly no benefit to anyone.
  • endgame 7mo ago
    Making each one implement input handling was also a dazzlingly bizarre design choice.
    • gf000 7mo ago
      Are they not just using libinput and that's it?
  • sho_hn 7mo ago
    > Why is Wayland so complicated? It's not particularly complicated, and certainly a lot simpler and cleaner than X11 in almost every way. The reality of the situation is that there's sort of a hateful half-knowledge mob dynamic around the topic, where people run into a bug, do some online search, run into the existing mob, copy over some of its "arguments" and the whole thing keeps rolling and snowballing. Sometimes this innocent, like OP discovering that UIs are actually non-trivial and there's different types of windows for different things (like in really any production-grade windowing system). So they share their new-found knowledge in the form of a list. Then the mob comes along and goes "look at this! they have a list of things, and it's probably too long!" and then in the next discussion it's "Did you know that Wayland has a LONG LIST OF THINGS?!" and so on and so forth. It's like politics, and it's cyclic. One day the narrative will shift again. The mob will not believe me either, for that matter, but FWIW, I've worked on the Linux desktop for over 20 years, and as the lead developer of KDE Plasma's taskbar and a semi-regular contributor to its window manager, I'm exposed to the complexity of these systems in a way that only relatively few people in the world are. And I'd rather keep the Wayland code than the X11 one, which I wrote a lot of.
    • flohofwoe 6mo ago
• vrighter 6mo ago
  it's not just "difficult to understand". It's that it doesn't allow the functionality the apps need. And you can't have a generic library targeting each wayland compositor implementation separately.