lmemsm

I've been investigating using sixel and a terminal program in place of options like X Windows and Wayland. Thought I'd share my research results so far.

The library libsixel is available at:
https://github.com/saitoha/libsixel
An SDL library modified to work with sixel is at:
https://github.com/saitoha/SDL1.2-SIXEL
There's a later fork of the sixel library here:
https://github.com/libsixel/libsixel
However, other projects like sixel support for SDL were not forked.

I started with the older libsixel and SDL1.2-SIXEL projects. The newer project uses Meson for building and I don't intend to get Meson or its dependencies up and running at this time. I was able to get libsixel to build on Windows and AIX. It needs some minor modifications to build on AIX. SDL with sixel support will not build on Windows. It was designed to work on a POSIX machine and would need to be ported to Windows (with a major rewrite) to work. I was able to get SDL with sixel support to build on AIX. That also needed some modifications. The patches at Perlz.org ( https://www.perzl.org/aix/index.php?n=Main.SDL ) were very helpful. Needed some other modifications as well and to configure it to build with sixel and not X Windows.

Once I got the libraries built, I needed a way to test it. mlterm ( http://mlterm.sourceforge.net/ ) has sixel support and it builds on a variety of platforms. So, I ran my tests through mlterm.

I built the SDL demo program fire because it didn't require a lot of support libraries and it has enough color to let me test if colors on an Endian system were being handled properly.

Here's what I found out. For a small example program, it seemed to run incredibly slow. Not sure how they ran the Doom program mentioned at the sixel site at a decent rate. The colors were reversed because it was an Endian system. I've been wanting to test some of the SDL programs I typically work with to see if I've coded for Endian systems properly or not. Hopefully, I'll be able to do that in the future.

Note: As a follow-up, I tested some of my SDL programs using X forwarding. Some of the programs I tried did have a problem with color when tested on a Big Endian system. However, the ones I specifically coded to handle colors on different systems appear to be displaying properly. So, my assumptions on how to work with color palettes on Big Endian systems appear to be validated. I built the fire demo using SDL with X Windows support and ran it using X forwarding. It is actually even slower than the sixel solution was. So, using X Windows with X forwarding to run GUI programs on another machine does not appear to be a good solution either.

I've been looking at various methods to replace X Windows and Wayland. There's nano-x, directfb which works with SDL and now I can add sixel to the list of options I've tried. Nano-x works great, but it was slower than X Windows on my computers. You can run more than one application at once and display them in windows on your screen. Using framebuffer or directfb works in some cases, but when I tried to run more than one application using a terminal splitting program, it was a mess. It's not slow. However, less programs can be built this way. SDL applications typically need to be set to use fullscreen options. As mentioned, similar to nano-x, sixel seems to be slow as well. I'm not sure how it will work with a terminal splitter program, but I assume it will do better than the framebuffer/directfb options. nano-x provides the greatest compatibility as far as number of programs that work with it. Since both it and sixel are slower options, I'm not sure sixel provides enough advantages over nano-x beyond the fact that it'll run in a terminal so you can access it by ssh on another system. You'd be very limited in what terminals you could successfully use though. One advantage of sixel is that you could run GUI programs in a terminal on Android using a method similar to what Termux uses. You could also run GUI programs on Windows using WSL without requiring an X Windows server. There's now a better solution for using GUI programs on later versions of Windows that doesn't require a separate X Windows installation. So, it may not be that useful to run GUI programs in a terminal using sixel on WSL, especially if the speed is much better using the other methods.

So, at this point, I'm wondering if I'm back to square one as to finding GUI options that will allow for quickly and easily building and for sharing applications. I'm still finding it easier to build and share applications targeted to Windows using Win32. They run on Windows operating systems (several versions) and many run on ReactOS and on Linux via Wine. There are other solutions for running Windows compatible programs as well. BoxedWine allows porting of Windows programs to other operating systems. Winebox creates an alternative operating system to Windows based on Android. I'd like to find some alternative solutions to using Win32 that are just as portable. I've also investigated building programs for DOS systems and using options like DOSBox and DOSemu. Was not thrilled with that alternative for various reasons. As Termux demonstrates, porting console programs often works well. One can build a console program statically and not have to worry about what libraries are available on another POSIX system. However, once a GUI is involved, it can be much more challenging (as the effort to get GUI programs working with WSL illustrates). Would be interested to hear from others who are looking into alternatives to X Windows and Wayland.