Wayland Archive

IceWM, the venerable window manager we’ve all used at some point in our lives, has released a new version, 3.5.0. It’s a relatively minor release, so you’ve got things like a new install option which will install an extra theme, a fix for porting to NetBSD 10, translation updates, and more such small improvements. The AddressBar, a command line in the taskbar that can be summoned with ctrl+alt+space, also got some love, with file argument completion and support for the cd and pwd commands. You can compile IceWM yourself, of course, but it’ll most likely find its way into your distribution’s repository quickly enough.

Linux auto tiling manager with hot corner support for Openbox, Fluxbox, IceWM, Xfwm, KWin, Marco, Muffin, Mutter and other EWMH compliant window managers using the X11 window system. Therefore, this project provides dynamic tiling for XFCE, LXDE, LXQt, KDE and GNOME (Mate, Deepin, Cinnamon, Budgie) based desktop environments. Simply keep your current window manager and install cortile on top of it. Once enabled, the tiling manager will handle resizing and positioning of existing and new windows. ↫ Cortile GitHub page I’ve always been mildly interested in trying out a proper tiling window manager – of which are millions – but installing and setting up an entirely new environment always felt a bit like overkill for something I’m just curious about instead of actually intending to use it permanently. This seems like a great solution to this issue.

X Server is slowly being deprecated in the Linux world and being replaced Wayland. Still X11 is an interesting protocol to look at from the perspective of binary communication and management of resource which require fast speeds. In this post I tried to cover basic information and create a simple but working app that is simple, defined in single file and easily compiles. No external code except libc was used. I find it fascinating when you can open black boxes and see how gears move each other. ↫ Hereket As much as the time of X has come and is now finally in the process of going, it’s still an incredibly powerful set of tools that even in a bare state can do way, way more than you think. X has come with its own window manager – twm – for decades, and it includes several basic applications like xedit, xclock, xterm, xeyes. Twm is actually pretty cool, and includes some features, like iconify to desktop, that I wish still existed in modern desktop environments. It’s quite bare-bones, though, and I doubt there’s anyone out there unironically using it today. As the linked article notes, even without advanced, complex libraries, toolkits, desktop environments, and so on, it’s entirely possible to create fully functional windows and applications with X. Of course, this makes perfect sense and shouldn’t be surprising – it’s the X Window System, after all – but you so rarely hear or read about it that you’d almost forget and just assume something like GNOME or KDE is an absolute requirement to use X.

Earlier this year, we talked about Niri, a very unique tiling window manager for Wayland that scrolls infinitely to the right. I’ve never seen anything quite like it, and while it seems polarising, I think it’s absolutely worthy of a dedicated niche. The project’s got a major new release out, and there’s a lot of improvements here. First and foremost, virtually all animations have been overhauled, and new ones have been added for almost every kind of interaction. The videos on the release page do a really good job of highlighting what they’re going for, and I think it looks great, and for the animation-averse, every individual animation can be turned off. Niri now also supports variable refresh rate, and the IPC mechanism has been improved. Among the smaller improvements is a welcome one: when using the touchscreen, the mouse cursor disappears. I really think this one has to be tried before judged, and I’m seriously contemplating setting up a Wayland environment just for this one, to see if it works for me. My window “flow”, if that makes sense, is already left-to-right, so the idea of having that effectively automated with an infinite canvas sounds very appealing to me, especially on smaller displays. I just need to figure out if it works in reality.

Every window system has windows, as an entity. Usually we think of these as being used for, well, windows and window like things; application windows, those extremely annoying pop-up modal dialogs that are always interrupting you at the wrong time, even perhaps things like pop-up menus. In its original state, X has more windows than that. Part of how and why it does this is that X allows windows to nest inside each other, in a window tree, which you can still see today with ‘xwininfo -root -tree‘. One of the reasons that X has copious nested windows is that X was designed with a particular model of writing X programs in mind, and that model made everything into a (nested) window. Seriously, everything. In an old fashioned X application, windows are everywhere. Buttons are windows (or several windows if they’re radio buttons or the like), text areas are windows, menu entries are each a window of their own within the window that is the menu, visible containers of things are windows (with more windows nested inside them), and so on. ↫ Chris Siebenmann This is wild.

Wayland and X.org are both part of freedesktop. Whatever maintenance is still happening on X.org is mostly being done by people who primarily work on Wayland. There isn’t some kind of holy war going on between The Wayland Developers who want to kill X.org, and The X.org Developers who believe it is great and want to keep it. They’re nearly all the same people, and they all want X.org to die. AFAIK there isn’t anybody who is actually clamoring to *do the work of maintaining X.org upstream*. There are people who don’t want it to die because Wayland doesn’t yet have the features they need or the NVIDIA proprietary driver doesn’t work well on Wayland or whatever, but AFAIK, none of those people is actually volunteering to maintain X.org long-term. ↫ Adam Williamson There’s really no clearer summary of the current state of affairs than this.

While there are a lot of Wayland compositors out there that aren’t too different from each other in terms of features, one of the more unique ones is Greenfield. The Greenfield Wayland compositor has been out there for a few years now as an in-browser HTML5-based solution that is continuing to prove itself capable and even fast enough for handling Linux gaming. ↫ Michael Larabel A rather genius idea for a Wayland compositor.

Niri is a scrollable, tiling window manager for Wayland. What does it mean for a tiling window manager to be scrollable? Windows are arranged in columns on an infinite strip going to the right. Opening a new window never causes existing windows to resize. Every monitor has its own separate window strip. Windows can never “overflow” onto an adjacent monitor. Workspaces are dynamic and arranged vertically. Every monitor has an independent set of workspaces, and there’s always one empty workspace present all the way down. ↫ Niri’s GitHub page Definitely an intriguing idea.

We’re hearing more about this recently because the transition is picking up steam. X11’s maintainers have announced an end to its maintenance. Plasma is going Wayland by default, following GNOME. Fedora is dropping X11 support entirely. We’re in the part of the transition where people who haven’t thought about it at all are starting to do so and realizing that 100% of the pieces needed for their specific use cases aren’t in place yet. This is good! Them being heard is how stuff happens. I wish it had happened sooner, but we are where we are, and there are a lot of recent proposals and work around things like remote control, color management, drawing tablet support, and window positioning. There will probably be an awkward period before all of these pieces are in place for all of the people. And for the those who really do suffer from showstopping omissions, I say keep using X11 until it’s resolved. No one’s stopping you. ↫ Nate Graham at Pointie Stick Will all the people who both can and want to work on X.org please raise their hands? Oh, no hands? What a shame.

You may have seen the news that Red Hat Enterprise Linux 10 plans to remove Xorg. But Xwayland will stay around, and given the name overloading and them sharing a git repository there’s some confusion over what is Xorg. So here’s a very simple “picture”. ↫ Peter Hutterer A more useful visualisation than I expected.

Wayland is all the rage those days. Distributions left and right switch to it, many readers of my previous article on writing a X11 GUI from scratch in x86_64 assembly asked for a follow-up article about Wayland, and I now run Waland on my desktop. So here we go, let’s write a (very simple) GUI program with Wayland, without any libraries, this time in C. In case you’re bored this weekend.

Cairo 1.18 was released today as the first major stable release to this 2D graphics library in five years. This vector-based graphics library is widely-used for a variety of purposes from GNOME’s GTK toolkit to other apps making use of Cairo for targeting different back-ends from PDFs to OpenGL contexts. Mozilla Firefox, WebKit, Mono, and many other open-source projects are notable users of Cairo. Cairo is something most end users don’t really have to think about or worry too much about, but it’s a crucial part of the open source operating system world. The most interesting change in 1.18 is that it drops support for a variety of old back-ends, most notably Qt 4, BeOS, and OS/2.

KDE’s Nate Graham talks about Wayland, and sums up both its history, current status, and the future. Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. I’ve read a lot of nervousness and fear about it lately. So today, let’s talk about it! Wayland is a needlessly divisive topic, mostly because the people who want to stick to X.org are not the same people with the skills required to actually maintain, let alone improve, X.org. Wayland should not be a divisive topic because there’s really nowhere else to go – it’s the current and future of the Linux desktop, and as time goes on, the cracks in X.org will start to grow wider and longer. In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well. My biggest – and basically only – issue with Wayland is that it’s very Linux-focused for now, leaving especially the various BSDs in a bit of a rough situation. There’s work being done on Wayland for BSD, but I fear it’s going to take them quite a bit of time to catch up, and in the meantime, they might suffer from a lack of development and big fixing in their graphics stack.

Adding screen savers to Wayland is not simply a matter of “port the XScreenSaver daemon”, because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. But that means that accomplishing that task means not just writing code, but engaging with whatever passes for a standards body or design committee in the Wayland world, and that is… how shall I put this… not something that I personally feel highly motivated to do. However, as I am the world’s foremost expert on screen savers on Unix-like operating systems, here are a few simple admonitions for young and old. Jamie Zawinski imparts his wisdom.