Wayland Archive
Graham’s TWM page has been around for like two decades or so and still isn’t even remotely as old as TWM itself, and in 2021 they published an updated version with even more information, tips, and tricks for TWM. The Tab Window Manager finds its origins in the lat 1980s, and has been the default window manager for the X Windowing System for a long time, now, too. Yet, few people know it exists – how many people even know X has a default window manager? – and even fewer people know you can actually style it, too. OK, so TWM is fairly easy to configure but alot of people, upon seeing the default config, scream ‘Ugh, thats awful!’ and head off to the ports tree or their distro sources in search of the latest and greatest uber desktop environment. There are some hardcore TWM fans and mimimalists however who stick around and get to liking the basic feel of TWM. Then they start to mod it and create their own custom dekstop. All part of the fun in Unix :). Graham’s TWM page I’ll admit I have never used TWM properly, and didn’t know it could be themed at all. I feel very compelled to spend some time with it now, because I’ve always liked the by-now classic design where the right-click desktop menu serves as the central location for all your interactions with the system. There are quite a few more advanced, up-to-date forks of TWM as well, but the idea of sticking to the actual default X window manager has a certain charm. I almost am too afraid to ask, because the answer on OSAlert to these sorts of questions is almost always “yes” – do we have any TWM users in the audience? I’m extremely curious to find out if TWM actually has a reason to exist at this point, or if, in 2024, it’s just junk code in the X.org source repository, because I’m looking at some of these screenshots and I feel a very strong urge to give it a serious go.
The goal is to be able to drag an icon from a background window without immediately raising that window and obscuring the drop target window when using the click-to-focus mode. This is a barebones description of what needs to happen. It assumes familiarity with code, protocols, etc. as needed. Quod Video The articles describes how to get there using both X and Wayland, and it’s clear there’s still quite a bit of work to do. At least on my KDE Wayland setups, the way it works now is that when I click to drag an icon from a lower Dolphin window to a higher one, it brings the lower window forward, but then, when I hover for a bit over the other window, it brings it back up. Of course, this only works if the destination window remains at least partially visible, which might not always be the case. For usability’s sake, there needs to be an option to start a drag operation from one window to the next without altering the Z-order.
David Rosenthal, one of the primary contributors to the X Windowing System, has published an awesome blog post about the recent 40 year anniversary of X, full of details about the early days of X development, as well as the limitations they had to deal with, the choices they had to make, and the environment in which they were constrained. Once at Sun I realized that it was more important for the company that the Unix world standardized on a single window system than that the standard be Sun’s NeWS system. At C-MU I had already looked into X as an alternative to the Andrew window system, so I knew it was the obvious alternative to NeWS. Although most of my time was spent developing NeWS, I rapidly ported X version 10 to the Sun/1, likely the second port to non-DEC hardware. It worked, but I had to kludge several areas that depended on DEC-specific hardware. The worst was the completely DEC-specific keyboard support. Because it was clear that a major redesign of X was needed to make it portable and in particular to make it work well on Sun hardware, Gosling and I worked with the teams at DEC SRC and WRL on the design of X version 11. Gosling provided significant input on the imaging model, and I designed the keyboard support. As the implementation evolved I maintained the Sun port and did a lot of testing and bug fixing. All of which led to my trip to Boston to pull all-nighters at MIT finalizing the release. David Rosenthal They were clearly right. During those days, the UNIX world was using a variety of windowing systems, all tied to various companies and platforms. Standardising virtually the entire UNIX world on X aided in keeping UNIX compatible-ish even in the then-new graphical era, and X’s enduring existence to this very day is evidence of the fact they made a lot of right choices early on. Rosenthal also explains why one of the main alternatives to X, Sun’s PostScript-based NeWS, which was also co-developed by Rosenthal, didn’t win out over X. It had several things working against its adoptions and popularisation, such as Sun requiring a license fee for the source code, its heftier system requirements, and the fact it was more difficult to program for. After trying to create what Rosenthal describes as a “ghastly kludge” by combining NeWS and X into Xnews, Sun eventually killed it altogether. Of course, this wouldn’t be restrospective of X without mentioning Wayland. We and Jobs were wrong about the imaging model, for at least two reasons. First, early on pixels were in short supply and applications needed to make the best use of the few they were assigned. They didn’t want to delegate control to the PostScript interpreter. Second, later on came GPUs with 3D imaging models. The idea of a one-size-fits-all model became obsolete. The reason that Wayland should replace X11 is that it is agnostic to the application’s choice of imaging model. David Rosenthal This is about as close to a blessing from the original X Windowing System developers you’re ever going to get, but Rosenthal does correctly note that XWayland is a thing, and since not every application is going to be rewritten to support Wayland, X will most likely be around for a long time to come. In fact, he looks towards the future, and predicts that we’ll definitely be celebrating 50 years of X, and that yes, people will still be using it by then.
Today just so happens to be the 40th birthday of X, the venerable windowing system that’s on its way out, at least in the Linux world. From the original announcement by Robert W. Scheifler: I’ve spent the last couple weeks writing a window system for the VS100. I stole a fair amount of code from W, surrounded it with an asynchronous rather than a synchronous interface, and called it X. Overall performance appears to be about twice that of W. The code seems fairly solid at this point, although there are still some deficiencies to be fixed up. We at LCS have stopped using W, and are now actively building applications on X. Anyone else using W should seriously consider switching. This is not the ultimate window system, but I believe it is a good starting point for experimentation. Right at the moment there is a CLU (and an Argus) interface to X; a C interface is in the works. The three existing applications are a text editor (TED), an Argus I/O interface, and a primitive window manager. There is no documentation yet; anyone crazy enough to volunteer? I may get around to it eventually. Robert W. Scheifler Reading this announcement email made me wonder if way back then, in 1984, the year of my birth, there were also people poo-pooing this new thing called “X” for not having all the features W had. There must’ve people posting angry messages on various BBS servers about how X is dumb and useless since it doesn’t have their feature in W that allows them to use an acoustic modem to send a signal over their internal telephone system by slapping their terminal in just the right spot to activate their Betamax that’s hotwired into the telephone system. I mean, W was only about a year old at the time, so probably not, but there must’ve been a lot of complaining and whining about this newfangled X thing, and now, 40 years later, long after it has outgrown its usefulness, we’re again dealing with people so hell-bent on keeping an outdated system running but hoping – nay, demanding – others to do the actual work of maintaining it. X served its purpose. It took way too long, but we’ve moved on. Virtually every new Linux user since roughly 12-24 months ago will most likely never use X, and never even know what it was. They’re using a more modern, more stable, more performant, more secure, and better maintained system, leading to a better user experience, and that’s something we should all agree on is a good thing.
There’s incredibly good news for people who use accessibility tools on Linux, but who were facing serious, gamebreaking problems when trying to use Wayland. Matt Campbell, of the GNOME accessibility team, has been hard at work on an entirely new accessibility architecture for modern free desktops, and he’s got some impressive results to show for it already. I’ve now implemented enough of the new architecture that Orca is basically usable on Wayland with some real GTK 4 apps, including Nautilus, Text Editor, Podcasts, and the Fractal client for Matrix. Orca keyboard commands and keyboard learn mode work, with either Caps Lock or Insert as the Orca modifier. Mouse review also works more or less. Flat review is also working. The Orca command to left-click the current flat review item works for standard GTK 4 widgets. Matt Campbell One of the major goals of the project was to enable such accessibility support for Flatpak applications without having to pass an exception for the AT-SPI bus. what this means is that the new accessibility architecture can run as part of a Flatpak application without having to break out of their sandbox, which is obviously a hugely important feature to implement. There’s still a lot of work to be done, though. Something like the GNOME shell doesn’t yet support Newton, of course, so that’s still using the older, much slower AT-SPI bus. Wayland also doesn’t support mouse synthesizing yet, things like font, size, style, and colour aren’t exposed yet, and there’s a many more limitations due to this being such a new project. The project also isn’t trying to be GNOME-specific; Campbell wants to work with the other desktops to eventually end up with an accessibility architecture that is truly cross-desktop. The blog post further goes into great detail about implementation details, current and possible future shortcomings, and a lot more.
Less than a month after 3.5.0, IceWM is already shipping version 3.6.0. Once again not a major, earth-shattering release, it does contain at least one really cool feature that I think it pretty nifty: if you double-click on a window border, it will maximise just that side of the window. Pretty neat. For the rest, it’s small changes and bug fixes for this venerable window manager.
Wayland 1.23.0 has been released. This new release includes the usual bugfixes and protocol clarifications, a number of new features few of us will really understand because we lack the expertise, and most importantly of all: OpenBSD support. That’s it. That’s the news.
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.
Ordinary modifiers are normally straightforward, in that they are additional keys that are held down as you type the main key. Control, Shift, and Alt all work this way (by default). However, some modifiers are ‘sticky’, where you tap their key once to turn them on and then tap their key again to turn them off. The obvious example of this is Caps Lock (unless you turn its effects off, remapping its physical key to be, say, another Ctrl key). Another example, one that many X users have historically wound up quietly cursing, is NumLock. Why people wind up cursing NumLock, and why I have a program to control its state, is because of how X programs (such as window managers) often do their key and mouse button bindings. Chris Siebenmann I always have an applet in my KDE panel that shows me if I have any sticky modifiers enabled without realising it. On some of my keyboards, this isn’t always easily noticable, especially when you’re focused on what’s happening on your display. A little icon that only shows up when a sticky modifier is engaged solves this problem, as it immediately stands out in your peripheral vision.
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.
Miracle-wm is a Wayland compositor built atop of Mir, and its core is a tiling window manager like i3 and sway. It intends to offer more features compared to those, though, gunning more for swayfx. The project, led by Canonical’s Matthew Kosarek, recently released version 0.2.0, which comes with a bunch of improvements. It supports sway/i3 IPC now, so that it can function in conjunction with Waybar, a very popular tool in the build-it-yourself Wayland window manager space. There’s also a new feature where individual windows can live on top (Z-axis wise) of the tiling grid, where they work pretty much like regular windows. Another handy addition is that the configuration can be automatically reloaded when you change it. Miracle-wm comes in a snap package, but rpm and deb will arrive in a few days, as well. As the version number suggest, this project is in heavy development.
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.
One of the somewhat odd things about my old fashioned X Window System environment is that when I ‘iconify’ or ‘minimize’ a window, it (mostly) winds up as an actual icon on my root window (what in some environments would be called the desktop), in contrast to the alternate approach where the minimized window is represented in some sort of taskbar. I have strong opinions about where some of these icons should go, and some tools to automatically arrange this for various windows, including the GNU Emacs windows I (now) use for reading email. Chris Siebenmann Iconification should be possible in any modern desktop environment, and it’s sad that this paradigm has pretty much entirely vanished. I would love for iconified windows to be treated essentially the same way as files, so you can move them around, drop them inside directories, and even move them from one computer to another (assuming they have the application in question installed). If I’m working on a project, and I have a bunch of LibreOffice documents, spreadsheets, browser tabs, notes in a text editor, some images open, and so on, I should be able to iconify them all, keep them in the project’s directory, and de-iconify them as if nothing had ever happened. Right now, you have to use files and application states for that, which is cumbersome and annoying. Sadly, advanced window management is dying. Shame.
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.
The Wayland ecosystem had a phenomenal year from much better NVIDIA proprietary driver support, Firefox ending out the year shipping with Wayland support enabled by default, KDE Plasma 6.0 will default to Wayland following many improvements on the KDE side, the Wine Wayland driver upstreamed in its initial form, XWayland continuing to be enhanced, and a lot of other software from desktop environments to apps continuing to embrace Wayland. Michael Larabel at Phoronix This train ain’t stopping. Dare I say 2024 will be the year of Wayland on the desktop?
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.
