![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
My ideal desktop GUIs
May. 24th, 2026 08:38 amWith the recent resurgence in using and maintaining legacy software with projects like XLibre and gtk2-ng, I started to rethink my own desktop strategy. Did I want to take the easy route and update a lot of legacy gtk2 software? There certainly are enough choices in software that work with gtk. I did build XLibre (on Debian with musl) and gtk2-ng (on Debian with musl and on Windows with original MinGW) from source. I haven't shared the build scripts for XLibre but I did upload some of my build scripts for gtk2-ng in case they may be of use: https://git.devuan.org/lmemsm/bldgtk After the experience, I found myself wanting a more lightweight alternative even more than before. So what would a more lightweight desktop environment look like? Glad you asked.
First, I should note that a lot of people enjoy collecting software that looks similar and going to great lengths to theme and give their computers a specific look. If that's your interest, check out projects like gtk2-ng and their growing themes collection. That just isn't a high priority for me. My personal preference is for something that's lightweight, with source code that's easy to understand and modify and that does one thing well. I prefer substance to flash. Portability is a priority since I want to use these programs at home or at work and not be locked into a particular operating system. I want applications and libraries on my system that can be understood and maintained by one person. That's especially important to me because I don't have a community to back up what I'm doing.
I maintain a comprehensive, curated list of GUI libraries written in C. I've searched for a GUI library that I would like for many years. I even wrote an article called "In Search of a Portable Screen Library" that appeared in the C/C++ Users Journal back in September, 1996. While I've never found that one elusive GUI I liked, I have found several useful options.
FLTK is pretty much the most lightweight, full featured GUI library I could find. It's not C, it's C++, but it has some nice applications that were created with it. It currently has 4 themes. One I helped to get added after a pen pal did a beautiful job creating it. I had to settle for a subset of his modifications to get it accepted, but it's still nice to have another choice. So, for now I'm using FLTK for any programs that require more extensive GUI functionality. I'm trying to resurrect and update legacy FLTK programs like APCStudio for audio editing and postoffice for email. FLTK already has some very helpful settings applications such as alsamixergui and flsynclient. Georg, creator of XFDOS and NanoLinux, took several FLTK programs and brought new life to them and even designed new ones to create a complete desktop. TinyCore Linux also uses FLTK for their desktop. Between these two sources and the apps that were listed at the FLTK site, one can piece together an entire desktop just of FLTK based programs. FLTK works on the major operating systems. However, if it's used with nano-x, it can be ported to Android, embedded systems and handheld devices. Later versions of FLTK have additions made to ease the creation of other backends without needing to rely on nano-x for portability. I've been working for a long time trying to get SDL to function as a viable backend.
However, I don't want to stop there. I've found several useful SDL applications including a SDL based PDF viewer, an ebook reader with text to speech capabilities using flite, a graphics viewer and a graphics slideshow program and font viewers. Another advantage of SDL is that it works on a wide range of systems from Linux and Windows to handheld devices and Android.
You can find a full range of applications for almost any need already written in curses. While it's fast and useful to run applications in console using options like BSDcurses, there is a port of pdcurses that works on top of SDL. So it can run anywhere that SDL does. While it looks like a text user interface instead of a GUI, using it with a SDL backend can make it function more like a standard GUI application. Most curses/ncurses based programs will work with pdcurses as well. I've been trying to update a nice curses based password manager that uses an earlier version of the keepass database format to work with a more up-to-date keepass format.
OpenGL is a great base for games and makes an interesting backend for developing a GUI. SDL and FLTK can integrate with OpenGL. SDL also uses OpenGL as a backend in some cases. Raylib is another very promising library that works on OpenGL. It was designed to make programming in C/C++ easy to learn. It can work with a GUI called RayGUI. Raylib and RayGUI are highly portable and work on a number of platforms. One other library I like that uses an OpenGL backend is otk. It's extremely lightweight (similar to single header projects). It has some very useful GUI controls and some useful example programs were created for it. OpenGL works on a number of platforms but what if you're on a platform where OpenGL drivers are not available? Mesa, the FOSS implementation of OpenGL, is another option. However, it can be a heavyweight library that's difficult if not impossible to build on many non-POSIX operating systems. There are several lighter implementations that tried to offer OpenGL 1.1 compatibility on handheld devices, older computer operating systems and devices that do not have OpenGL or OpenGLES drivers. One very well-known implementation is TinyGL. It provides a subset of OpenGL. It's been forked multiple times and many projects have added missing features. I've collected several patches and added even more missing features to one fork known as PicoGL. PicoGL has multiple backends including Nano-X, X11 and SDL. I've recently experimented with some success in trying to get otk to work with PicoGL and SDL as an alternative to OpenGL with X11 or Win32.
So while these various projects may all present different looks via their user interfaces and may even seem like random choices, I chose these options strategically with portability in mind. They can provide a coherent, unified porting strategy. OpenGL and/or SDL can be used as a base for many of these options providing portability to any of the operating systems that can support OpenGL or SDL. PicoGL can be used as a backend on systems where OpenGL is not an option. These three options run on multiple platforms. If X11, Wayland and Win32 aren't available on a system, they can work with nano-x or in framebuffer. If SDL works on a system, nano-x, pdcurses and PicoGL can work on that system since they all have SDL backends. I'm working on adding FLTK and otk to that list. If OpenGL is available on a system, SDL and Raylib work well with that. If nano-x works on a system such as FreeDOS or an embedded OS, FLTK and PicoGL can be ported using it. The goal is to make these components as portable as possible so they can be used on a wide variety of operating systems. They're also lightweight and fairly easy to build. They can run on more unusual operating systems and be more easily maintained. They may seem like a disparate group of libraries, but I think they could be pulled together and used to build on each other to improve portability and provide a way to run lightweight applications on a wide variety of platforms and operating systems.
I'm aware this type of project isn't going to be something of interest to the average user. It won't appeal to the person who prefers to use a package manager to install applications instantly or to the person who enjoys custom theming and making everything look coordinated on his or her system. I am primarily doing this for myself and will continue to work on these types of projects on my own. However, it would be fun to find others with similar interests to compare notes and possibly brainstorm, find new programs to port or share patches to bring new life to some older applications. Imagine running a set of lightweight applications on a very old laptop or computer or a handheld device. If it runs efficiently on older computers, it will run even faster on modern ones. It also gives one person the opportunity to know how to build and maintain the applications on his/her system. That person isn't stuck waiting for a patch from upstream or worrying about whether a favorite project will be abandoned. So, if anyone is interested in discussing a GUI landscape like this further, feel free to contact me on Mastodon (https://fosstodon.org/@lmemsm) or by email. Let's talk.
First, I should note that a lot of people enjoy collecting software that looks similar and going to great lengths to theme and give their computers a specific look. If that's your interest, check out projects like gtk2-ng and their growing themes collection. That just isn't a high priority for me. My personal preference is for something that's lightweight, with source code that's easy to understand and modify and that does one thing well. I prefer substance to flash. Portability is a priority since I want to use these programs at home or at work and not be locked into a particular operating system. I want applications and libraries on my system that can be understood and maintained by one person. That's especially important to me because I don't have a community to back up what I'm doing.
I maintain a comprehensive, curated list of GUI libraries written in C. I've searched for a GUI library that I would like for many years. I even wrote an article called "In Search of a Portable Screen Library" that appeared in the C/C++ Users Journal back in September, 1996. While I've never found that one elusive GUI I liked, I have found several useful options.
FLTK is pretty much the most lightweight, full featured GUI library I could find. It's not C, it's C++, but it has some nice applications that were created with it. It currently has 4 themes. One I helped to get added after a pen pal did a beautiful job creating it. I had to settle for a subset of his modifications to get it accepted, but it's still nice to have another choice. So, for now I'm using FLTK for any programs that require more extensive GUI functionality. I'm trying to resurrect and update legacy FLTK programs like APCStudio for audio editing and postoffice for email. FLTK already has some very helpful settings applications such as alsamixergui and flsynclient. Georg, creator of XFDOS and NanoLinux, took several FLTK programs and brought new life to them and even designed new ones to create a complete desktop. TinyCore Linux also uses FLTK for their desktop. Between these two sources and the apps that were listed at the FLTK site, one can piece together an entire desktop just of FLTK based programs. FLTK works on the major operating systems. However, if it's used with nano-x, it can be ported to Android, embedded systems and handheld devices. Later versions of FLTK have additions made to ease the creation of other backends without needing to rely on nano-x for portability. I've been working for a long time trying to get SDL to function as a viable backend.
However, I don't want to stop there. I've found several useful SDL applications including a SDL based PDF viewer, an ebook reader with text to speech capabilities using flite, a graphics viewer and a graphics slideshow program and font viewers. Another advantage of SDL is that it works on a wide range of systems from Linux and Windows to handheld devices and Android.
You can find a full range of applications for almost any need already written in curses. While it's fast and useful to run applications in console using options like BSDcurses, there is a port of pdcurses that works on top of SDL. So it can run anywhere that SDL does. While it looks like a text user interface instead of a GUI, using it with a SDL backend can make it function more like a standard GUI application. Most curses/ncurses based programs will work with pdcurses as well. I've been trying to update a nice curses based password manager that uses an earlier version of the keepass database format to work with a more up-to-date keepass format.
OpenGL is a great base for games and makes an interesting backend for developing a GUI. SDL and FLTK can integrate with OpenGL. SDL also uses OpenGL as a backend in some cases. Raylib is another very promising library that works on OpenGL. It was designed to make programming in C/C++ easy to learn. It can work with a GUI called RayGUI. Raylib and RayGUI are highly portable and work on a number of platforms. One other library I like that uses an OpenGL backend is otk. It's extremely lightweight (similar to single header projects). It has some very useful GUI controls and some useful example programs were created for it. OpenGL works on a number of platforms but what if you're on a platform where OpenGL drivers are not available? Mesa, the FOSS implementation of OpenGL, is another option. However, it can be a heavyweight library that's difficult if not impossible to build on many non-POSIX operating systems. There are several lighter implementations that tried to offer OpenGL 1.1 compatibility on handheld devices, older computer operating systems and devices that do not have OpenGL or OpenGLES drivers. One very well-known implementation is TinyGL. It provides a subset of OpenGL. It's been forked multiple times and many projects have added missing features. I've collected several patches and added even more missing features to one fork known as PicoGL. PicoGL has multiple backends including Nano-X, X11 and SDL. I've recently experimented with some success in trying to get otk to work with PicoGL and SDL as an alternative to OpenGL with X11 or Win32.
So while these various projects may all present different looks via their user interfaces and may even seem like random choices, I chose these options strategically with portability in mind. They can provide a coherent, unified porting strategy. OpenGL and/or SDL can be used as a base for many of these options providing portability to any of the operating systems that can support OpenGL or SDL. PicoGL can be used as a backend on systems where OpenGL is not an option. These three options run on multiple platforms. If X11, Wayland and Win32 aren't available on a system, they can work with nano-x or in framebuffer. If SDL works on a system, nano-x, pdcurses and PicoGL can work on that system since they all have SDL backends. I'm working on adding FLTK and otk to that list. If OpenGL is available on a system, SDL and Raylib work well with that. If nano-x works on a system such as FreeDOS or an embedded OS, FLTK and PicoGL can be ported using it. The goal is to make these components as portable as possible so they can be used on a wide variety of operating systems. They're also lightweight and fairly easy to build. They can run on more unusual operating systems and be more easily maintained. They may seem like a disparate group of libraries, but I think they could be pulled together and used to build on each other to improve portability and provide a way to run lightweight applications on a wide variety of platforms and operating systems.
I'm aware this type of project isn't going to be something of interest to the average user. It won't appeal to the person who prefers to use a package manager to install applications instantly or to the person who enjoys custom theming and making everything look coordinated on his or her system. I am primarily doing this for myself and will continue to work on these types of projects on my own. However, it would be fun to find others with similar interests to compare notes and possibly brainstorm, find new programs to port or share patches to bring new life to some older applications. Imagine running a set of lightweight applications on a very old laptop or computer or a handheld device. If it runs efficiently on older computers, it will run even faster on modern ones. It also gives one person the opportunity to know how to build and maintain the applications on his/her system. That person isn't stuck waiting for a patch from upstream or worrying about whether a favorite project will be abandoned. So, if anyone is interested in discussing a GUI landscape like this further, feel free to contact me on Mastodon (https://fosstodon.org/@lmemsm) or by email. Let's talk.
![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}