No love for native GUI toolkits

Look and feel is one of the things of the 90s we no longer covet.

Soon I am going to be embarking on my first installation of Alpine Linux for a desktop. Besides the implication of switching away from GNU libc to musl, I am also taking it as an opportunity to switch away from X11 to Wayland, and in doing so find out just how many of my favourite Linux applications will depend on XWayland. I don’t expect this to be a smooth ride, but I do expect to come out of the other end with a useful computer at least.

Being a power user of computers often makes me reflect my desires as one onto my development work. I look upon things like SciTE and wonder, “was this really the best approach after all?” I mean, graphical toolkits have two things they need to provide besides their functionality: enough abstraction to enable hardware acceleration where possible with a seamless, usable software fallback where not, and the often-mentioned ‘native look and feel’. I’m just not sure that the latter really matters anymore.

One of the reasons I can think of as to why is because most corporations keep changing their look and feel over and over, so no one has any attachment to them anymore. I used to love the look and feel of Windows XP style UI elements, but that operating system was taken off of extended support before I graduated high school. That was over ten years ago! Who but a cachet of vapourwave artists cares to remember that now? Apple has done much the same, and Google has also brought this trend of rearranging the deck chairs on the Titanic to mobile. Linux never had much consistency anyway, so with all of that in mind, the software architect in me was poised to ask, “why not just make an OpenGL 1.1 context with SDL and engineer the toolkit myself?” Indeed.

OpenGL 1.1 has the rare honour of working on Microsoft Windows as far back as Windows 95 without the need for things like GLEW or GLAD. It’s the only version natively supported by Windows to this very day, and provides a software implementation which doubles as a trampoline to any graphics drivers you might have installed, giving you exactly what you need in all scenarios. For the relatively simple geometries of graphical user interfaces, the API is enough.

Since the library question is thereby answered, my attention turns then to the architecture of the rendering engine underlying any widget toolkit. This is where it became clear to me that I could reach even farther than what the support matrix of OpenGL 1.1 provides by making the rendering architecture revolve around vector graphics divided into logical blocks of 8×8 pels (my term for software pixels, which don’t necessarily correspond 1:1 to physical pixels). With this, it becomes practical to port the rendering system to something as primitive as the Game Boy, not to mention all sorts of 2D ‘Windows accelerators’ that were so common in the early 1990s. And with the insistence of vector graphics as the sole drawing primitives, the experience can scale trivially onto the most modern ultra-high-resolution displays people enjoy today.

The only thing this renderer is missing now is a name. And yes, if you were wondering, it will be written entirely in ANSI C. When look and feel don’t hold currency, this is going to be the best application rendering backend you could ask for.