I've covered SDL and FLTK based applications. Now I'd like to discuss pdcurses and ncurses based ones. ncurses is found on many POSIX systems especially Linux. pdcurses was used primarily on DOS and Windows systems. Support for X and SDL was later added. The X support uses some legacy functions, so it doesn't build well on modern Linux systems. However, the SDL support allows pdcurses to be ported to any system that supports the SDL library. That means it can run on systems like Syllable and Haiku not just POSIX systems with X Windows. ncurses worked only on POSIX systems for a long time, but more recently support was added for Windows and MinGW32.

So which is the better library to use? Depends on your needs. ncurses is very stable, provides good Unicode support on many operating systems and offers added functionality like panels, menus and forms. On POSIX systems, it runs in console mode, so you can run applications outside X Windows (or Wayland) or on systems with no X Windows installed. Applications built with ncurses can also be used via ssh and telnet. Unicode support for pdcurses is currently limited to UCS-2 (16 bits). It designed in such a way that expansion to UTF-8 or UTF-32 would mean major changes. It works in console mode, but on DOS/Windows only. You'll typically need X Windows if you run pdcurses on a POSIX systems. There are some work-arounds to this. You can use DirectFB or nano-x to run SDL in framebuffer and use pdcurses with the SDL backend. However, applications run in framebuffer mode aren't usable with ssh and telnet. You'll need something like vnc to remotely access them. There is also a pdcurses fork called win32a which provides native Windows support and better support for colors. pdcurses has some functions that are not typically standard with ncurses/curses such as specific mouse and clipboard functions. However, it lacks a lot of the extras that ncurses adds such as menu and form support. Both pdcurses and ncurses have functions for the standard ASCII character set and for wide characters (wchar). However, keep in mind that wchar is 16 bits on Windows (and DOS djgpp) systems and 32 bits on most POSIX systems (such as Linux and BSD). Personally, I prefer to use UTF-8 whenever possible for Unicode. I also prefer the new char32_t (or uint32_t if not available) in place of wchar_t in all my applications with internationalization support. However, pdcurses/ncurses aren't designed for these options. Of the two libraries, ncurses better supports characters in a Unicode character set beyond the initial 16 bits and is better designed to handle large character sets.

Even though ncurses has many advantages over pdcurses, I still like to work with pdcurses. It's a more compact library, with the backend code separated from the rest of the code to make it easy to port to other platforms. With this design and with its SDL support, it's easy to get pdcurses working on a wide variety of operating systems including some places ncurses has not been ported. As mentioned, libform and libmenu are not a part of pdcurses, but their functionality is available with ncurses. It turns out that other versions of curses did not originally have support for forms and menus and they were separate libraries. BSD still has libform and libmenu that work with its version of curses. I found it very easy to port libform and libmenu to work with pdcurses. There were some bugs in the libraries which I'm surprised no one has fixed yet, but I have patches for them. One other advantage of pdcurses built with SDL is that you can intermix SDL and pdcurses commands. pdcurses/ncurses are primarily console/text libraries. SDL offers graphics support. You can mix graphics from SDL with text from pdcurses and use pdcurses as a text user interface (GUI alternative) for SDL. That's a really nice option when developing SDL applications.

I've added SDL 2.x support to pdcurses, so it will port to systems that support SDL 1.x or SDL 2.x. pdcurses with the SDL backend, used bitmaps to represent characters. That curtailed Unicode support. I've added support to use SDL_TTF for drawing characters. Now the only limitation on characters that can be used with PDCurses is the 16 bit limit to the character size built into the system. It should be possible to expand that to 32 but it would require modifications that would affect the entire design. Also, since curses only supplies ASCII and wchar support for routines, a Windows (or DOS) system would still be limited to 16 bits. One would need a new set of routines with UTF-32 support or UTF-8 support. The current routines could not be used to support 32 bit characters on systems where wchar is limited to 16 bits. The ASCII functions are designed to work with one character at a time not several which UTF-8 might require.

Some of my patches for better internationalization support for pdcurses have been added back in to the official version of pdcurses. All of my pdcurses patches plus documentation on them and my build scripts can be found by following the archive link at http://www.distasis.com/cpp/lmbld.htm I'm interested in adding some of the win32a patches and continuing to improve support for internationalization in the future. If anyone wants to discuss design ideas for continuing to add better Unicode support for pdcurses, please contact me.

The good news with ncurses/pdcurses based applications is that it's relatively easy to port them from one version of curses to another in many cases. It may require changes in the names of header files. Non-portable functions such as those supporting a mouse may not be available on some systems. However, one can typically use any application designed for a particular version of curses with another version of curses. That does not mean ncurses/pdcurses applications can easily be ported to other operating systems. For instance, if an application uses functions that aren't very portable across platforms (such as fork which isn't easy to emulate on Windows and doesn't work on DOS), it will be very difficult to port that application. Unfortunately, many ncurses applications do just that and use POSIX functions that aren't widely ported to non-POSIX systems.

So, let's talk about some of the applications that I've found that do port across a variety of operating systems and can be built with pdcurses.

There are several ncurses based hex editors available. I personally like the interface for ncurses hexedit. It reminds me of the kzap program I used to use with DOS, so I find it user-friendly. shed is another interesting option. It handles large file sizes extremely well.
You can find the programs here:

I have patches/build scripts for ncurses hexedit to work with pdcurses and port to other platforms. I've built shed on Windows before, but haven't created my own build scripts/patch set for it yet.

There aren't a lot of music applications that work well in console mode and provide a text user interface, but there are some. The ones that come to mind are TiMidity++ and GramoFile. Make sure if you intend to work with TiMidity++ that you start with the source from version control not the very old, outdated tarball at Sourceforge. Many features, including better Karaoke midi support, have been added since the tarball was created. I find it discouraging that distributions such as Debian refuse to update to the latest supported version of this project. I always build TiMidity++ from source myself to make sure I have the updates I need. I'm currently working on a build script for TiMidity++ that will allow me to build it as a library so it can be used with other applications. I currently have build scripts for TiMidity++ and freepats (Open Source sound fonts used with TiMidity++) and gramofile.

I originally looked for library versions of libform and libmenu because I thought a lot of curses applications would make use of these features. Turns out, not as many use it as I originally estimated. One program that makes use of the functionality for these libraries is ckpass. It's a console based password keeper that is compatible with KeePass 1.x format. That means, if you want a lightweight alternative to the earlier versions of KeePass or KeePassX, you can still have console access to your passwords. The program looks great and it's easy to use. Unfortunately, it offers just read-only support for viewing password information. There's no easy way to modify password information using the program. However, it isn't that hard to add code to allow editing as well as viewing of passwords using libform. I'm working on some modifications to ckpass to give it more functionality, so it will become a useful, more lightweight replacement to other password storage alternatives. There are other command line based password storage options available and some even use portable formats so that you can find cross-platform solutions. However, I like the idea that ckpass supports the KeePass 1.x format which many other GUI password programs also use. This is the link to the original ckpass project:

The final category I'll cover is the text editor category. There are a great many text editors that work in console mode or build with ncurses as can be seen from the listings at TextEditors.org ( http://texteditors.org/cgi-bin/wiki.pl ). However, the large majority of them are not highly portable.

When the competition between vi and emacs comes up and people start debating what should be the default editor on a Unix or Linux system, I typically skip both and go with nano. nano was based on the pico text editor. It wasn't a fork. It was coded from scratch, so there would be no issues with code licenses. pico was the main editor for the alpine mail system. Compared to other editors with unusual key sequences that you need to memorize to get anything to work, I find it very user-friendly. It has a menu and easy access to help if you forget what command keys you need to perform a specific function. My personal preference is to use a programming editor that will allow you to map key commands however you see fit. That avoids large learning curves if you didn't originally use vi or emacs as your first text editor and memorize their commands. However, if a text editor with keymapping support is not available, a user-friendly text editor with easy to access command menus and help descriptions is a good second choice. Most POSIX systems I work with have either pico or nano available or they can be installed fairly easily. So, if I need to do a quick edit from the console on a POSIX system, my default editor is typically nano or pico. One major drawback to pico is that it only handles one file at a time. You cannot have multiple files open and flip between editing them or cut and paste between them. nano adds support for multiple files, but the commands to switch aren't particular easy to remember.

I did a port of nano to Windows several years ago. There's a lite way to build nano (tiny) and a way to build it with more functionality. Building it the lite way and adding some modifications for porting, I was able to compile it successfully on Windows. So, while it didn't provide all the functionality I used on POSIX systems, it did work on Windows. A few years ago, I found a Windows port of nano on github. It didn't provide extra functionality, but it was interesting to see how the author went about porting the application and the differences between my port and that one. According to the nano editor FAQ, it now looks like there's some official support for Win32. However, when I tried to build the latest version, I still ran across a lot of the same issues as when I built previous versions. Only the lite version is supported for Windows. There were some assumptions about MinGW types that aren't true for all versions of MinGW. Rather than using configure for what it was designed for and testing if there needs to be a work-around for a particular system, the code has ifdefs that assume MinGW always handles things wrong and tries to fix the situation. In the process, it causes errors in the build for MinGW systems that do handle the situation properly. Guess I'll need to stick with my port or a Windows specific port like the one at github if I want nano to build properly on Windows.

nano is a great lightweight alternative for a text editor that works on a large variety of operating systems. When I need to modify a file and want an editor to quickly call from the command line, it is often my editor of choice. You'll find the source code and more information on nano at:

As I mentioned, I prefer programming editors that have good support for key-mapping. The scintilla text editing component offers just that. A large variety of Open Source editors, including SciTE (my favorite GUI editor) and fxite (lightweight FOX Toolkit based GUI editor), use the scintilla text editing component. While fxite is lightweight and works well on older systems, it requires X Windows on POSIX systems and the FOX Toolkit to build it from source. I wanted something even more lightweight. I did a search of the various editors that make use of the scintilla text editing component and I ran across textadept. It is a GUI text editor, but there's a ncurses based version that works from the console. I found it relatively easily to build the editor on Windows using pdcurses. So, it's rather portable. If I had to pick a console based editor besides nano and pico, textadept would be it.

There are ncurses front ends to some applications I work with such as hunspell and prozilla, but I typically don't use the front ends. I prefer using hunspell via command line or integrated with a programming editor. There's a nice FLTK front end for prozilla that is highly portable. One other ncurses based application I'll mention is WordGrinder. I typically see it mentioned on sites and blogs that specialize in discussing console based applications. It has many of the features of a word processor. The current web site for it is:

If you have other recommendations for useful, cross-platform portable ncurses/pdcurses/curses based applications, I'd love to hear ( http://www.distasis.com/connect.htm ) about them. It would be great to add more helpful applications to this list. I'm also very interested in the possibilities of using pdcurses/libmenu/libform as a text user interface (GUI alternative) for SDL applications.
It's fun to discover new lightweight applications. They work well on newer computer systems as well as older or slower computers and low resource machines like many mobile devices. You can run more of them at once. If they're not well-known, they can actually be more secure sometimes (using the security through obscurity principle). I also personally prefer portable applications. That way, you can use the same programs on any operating system. You don't have to relearn new programs for each system you work with.

It can be quite a challenge to find new lightweight applications. I've read several threads on forums where users post their favorite lightweight applications. Many truly are not lightweight by standards that take into consideration memory usage, lines of code, compilation time and/or number of dependencies (libraries).

One way to find lightweight applications is to look for programs built with lightweight GUIs. I've seen a few comparisons of GUI performance. This one is particularly good because it tests the various GUIs and gives statistics:
I was rather surprised by the SDL2 results. Generally, the time it takes to build a GUI from source is one good indication of complexity. FLTK and SDL both build quickly from source compared to the other GUI frameworks mentioned. So, I was surprised that SDL2 scored so badly on the memory usage tests. I'd be curious to know if SDL 1.2.x (which many systems still use) would show a large improvement. Another surprise was how well Tcl/Tk did in the tests. I typically think interpreted languages have worse performance than compiled ones. It would be interesting to see some statistics on response times for similar applications created with these GUIs.

I often go through various source repositories such as Sourceforge, github, etc. looking for code written using specific user interfaces in order to find new and interesting applications. Standard search engines are another way to search for programs. The user interfaces I'm personally most interested in at this point are FLTK, pdcurses/ncurses, SDL and command line programs. These types of applications are typically more lightweight or designed to do one thing well. Know of any other lightweight GUIs or TUIs (text user interfaces)? Please share your recommendations and why you like them.

There are some nice blogs for finding and discussing minimalistic (or in some cases maximalistic) programs. Unfortunately, many are no longer very active. Some favorites are:

If you know of others, I'd love to hear about them.

One can also look for lightweight distributions and see what programs they have in their repositories or read their forums for more suggestions. Some of the interesting distributions to check are TinyCore Linux (uses several FLTK programs), Nanolinux (uses more interesting FLTK programs), Rogue Class Linux (uses several SDL programs), Puppy Linux, AntiX (Debian based), INX ( http://inx.maincontent.net/ ), Absolute Linux (Slackware based), 4MLinux ( https://sourceforge.net/projects/linux4m/ ), OLPC. Typically DSL and Puppy get mentioned when people list lightweight Open Source systems. There's been no active development on DSL in a long time and the forums are very quiet. I also found Puppy a little too resource intensive on one of my older machines. FreeBSD performed much better on that system. Puppy Linux has some interesting discussions in their forums.

Linux systems that work in framebuffer mode using DirectFB, nano-x and other alternatives also typically contain many interesting, unusual and lightweight applications. Nanolinux and Rogue Class Linux are in this category.

One can also look at operating systems and development projects that use more lightweight C libraries (such as uclibc and musl). Those projects typically gravitate to choosing lightweight applications, command line and console based programs and lightweight tools like Busybox and Toybox.

Alternative operating systems often offer interesting lightweight application choices. Syllable and Haiku often use SDL programs and other lightweight applications that are easier to port to those systems. Systems like Minix and ELKS are also interesting to investigate. Minix 3 uses a lot of the programs that BSD systems do, but earlier versions of Minix include some interesting alternatives. XFDOS includes many interesting FLTK applications. Plan 9 is interesting as well, but not many of the programs used on this system have been ported to other systems. Another good place to look for unusual applications is on mobile devices.
Here are some application lists from Syllable and Agenda:

I'd love to find more places to discuss lightweight applications. If you've written an article on the topic, please share it. If you know of a good blog, forum, mailing list or other resource, please let me know ( http://www.distasis.com/connect.htm ). If you'd like to discuss your favorite C/C++ applications further, you're welcome to use the CppDesign mailing list ( http://groups.yahoo.com/group/CppDesign ) as a forum.
I covered SDL based applications. Now, I'd like to cover FLTK based applications for desktops and/or productivity.

While there isn't as much FLTK application development going on as I would like, there are some projects that specialize in using FLTK. TinyCore Linux is probably the most well-known Linux project that uses several FLTK applications. Nanolinux is based on TinyCore but uses nano-x as a lightweight alternative to X Windows. The developer of NanoLinux uses mainly FLTK applications and has modified and updated several FLTK applications to give them new life. He's also created some of his own where good alternatives did not exist. The Equinox Desktop Environment also uses FLTK, but it typically requires another EDE specific library along with FLTK support. Also, EDE users don't always look for FLTK applications for their desktops. Some will typically use anything they consider lightweight (whether it really is lightweight or not). A few mobile devices use FLTK as their main GUI. Users of those systems have developed some interesting applications for their devices.

There are several versions of FLTK. Applications may work with one version and not another. I've spent a lot of time searching for applications and porting applications to the latest version. I did try to update the FLTK software links list at the official FLTK web site with information on what worked with the latest version of FLTK and with information on newer FLTK applications, but was unable to add some of the newer, more interesting FLTK applications out there. So, this is my definitive list at this point in time of the best FLTK applications available. For more information on FLTK and applications, see also http://www.distasis.com/cpp/scrlib.htm#fltk

I'm sure I haven't covered everything and as mentioned, check NanoLinux and Tiny Core Linux for more FLTK based applications. I'm always looking for new, portable, lightweight FLTK based applications. If you know of something I may have missed or you're working on a new FLTK based project, please contact me.


Shows disk usage. Works on POSIX systems with du command. I have patches to port this to Windows.

Calculator. The FLTK web site link includes information on some of my patches to get it to build successfully as well as link to the original source code.

Graphical diff program.

Traverse directories and find file differences. Some of it was based on fldiff.

Password manager. I ported this to work with the latest versions of FLTK and tinyxml2. It's interesting, but at this point, I'd prefer a Keepass compatible password manager. I'm looking into chkpass as a lightweight alternative for password management.


prozgui for prozilla
Fast file downloader. I have patches for building and to port this to Windows. I use a version based on GNU GPLv2 development instead of the GNU GPLv3 development.

IRC client. Based on MegaIRC, but with a lot of cleanup. I have patches to add gettext/libintl support. This is the best option for IRC using FLTK that I've found to date.

This has good potential as a threaded IRC client. It can handle multiple connections. I could get it to build on Windows either with patches or a build of MinGW with POSIX instead of Windows native threading support. It needs some work on storing IRC connections. Doesn't seem to remember any connections once you leave the application.


There are two webkit based browsers for FLTK. That's great news for FLTK applications users. What's not so great is that they don't port well to non-POSIX systems. If you want the most lightweight webkit based browser (and webkit browsers are not by nature lightweight), I'd go with either of these options instead of the many other webkit ports out there.

I was able to get the original version of netrider to port to Windows and a Windows version of it is available at Sourceforge. However, when I upgraded the version of my MinGW compiler, I was no longer able to build netrider. Seems the webkit developers took some shortcuts in the older code that really weren't up to C++ standards. Netrider upgraded to a later version of webkit (which fixed the compiler issue), but the newer version was never ported to Windows.

This was never ported to Windows although it might be easier to port that the latest version of Netrider. It uses makefiles created by the developer instead of cmake.

When people talk about FLTK based web browsers, Dillo always comes up. However, Dillo is the opposite of what I think of when I think about portable code. One developer decided to fork Dillo and make it more structured and easier to port. He's really done a wonderful job on cleaning up the code. I'd recommend this browser over Dillo if you're interested in doing anything with the source code or need a lightweight HTML viewer for FLTK. DPlus is also the lightest browser I could find that could display output from diffh properly. Most console browsers like lynx had trouble rendering the color differences in the output.

While this is meant as a utility rather than a web browser, I used DPlus as the starting point for my HTML/CSS based dialog replacement.

Mail clients

The developer of Nanolinux wrote a nice, basic, stable e-mail client. (He also reused part of my Open Source POP3 e-mail code.)

This has a lot of potential. It took a long while to get it to build with the latest version of FLTK and it's still kind of buggy. I also needed to update helper libraries fl_toggletree and fleditor to work with the latest FLTK. The interface is a lot of like sylpheed and foxmail. I would love to see some new development on this and would be happy to help update it.

There was a nice, very basic, stable e-mail client at Sourceforge. Doesn't appear to be available from there any longer.

RSS reader
Gautier's RSS reader
This one has a lot of potential. It has an attractive user interface that's easy to work with. However, it does have the ability to sort RSS posts at this point at time. It needs to be used in conjunction with a script and tools like curl to download the RSS feeds. It's basically just a reader. It uses SQLLite to store the RSS data so it can potentially provide fast access to RSS posts. I'd love to see some further development done on this project.


Cross-platform VLC based media player.

Unfortunately, this only works on POSIX systems so far. I have been able to build it on Cygwin as well as BSD and several Linux systems. This might be portable to more platforms using nano-x (and possibly SDL as the backend for nano-x), but I did not get very far in investigating this option. It is my favorite xine front end and is more lightweight than many of the other xine front end options. It provides a variety of features including a nice visualization component for use while playing music.


Simple Audio recorder and player based on Sox. I have done some work to port this one to Windows.

Midi keyboard.

Audio effects program to stretch sounds.

After more than one try to get this to build with the latest version of FLTK, I finally managed to get this working. It's a nice, lightweight audio editor. It doesn't display multiple tracks like Audacity. It does not have good support for playing or recording wave files. It's basically just a wave file editor. Was considering using libsox or another Open Source sound library to add support for playing wave files.

There is a fork of FLTK called NTK. It isn't as portable as FLTK and requires POSIX/X Windows support. A suite of audio applications were created with it.


This is a great, lightweight graphics editor. I really like this one.

Specialized graphics editor for coloring old photos.

Other graphics and drawing options include Antipaint and Cinepaint. Antipaint was updated to work with the lastest version of FLTK and to improve portability by the developer of Nanolinux. You'll find it at the Nanolinux web site. At one point Cinepaint decided to port their project from GTK to FLTK. You'll find some older versions with some FLTK support and utilities. However, the FLTK port is not actively developed.


The Daily Journal is a Personal Information Manager (PIM). It has several nice features including the ability to set alarms to remind you of appointments. I use one of the older versions (0.7) which ports well to newer versions of FLTK and, per my recommendation, so does NanoLinux.

Simple todo list. Haven't used it in a while, but if you're looking for a todo list program, it's an option.

PDF/Ebook Readers

A functional, basic PDF viewer and archived image viewer. I really like this one. It requires a compiler with later C++ support to build. Needs minimal dependencies, mainly libarchive and poppler. While poppler isn't as fast as mupdf at rendering, this still works pretty fast.

Image viewer with plugin support for mupdf and poppler.

There's also flaxpdf which is optimized for efficiency and uses mupdf. However, it's not at all portable to non-POSIX systems.

I tried BDReader as well but there are a lot of dependencies involved in building this.

File managers

I don't use any of these and personally prefer the SDL based file manager mentioned earlier. However, they're nice lightweight GUI file managers. I'm sure there are a few others not mentioned below as well.



Other POSIX only FLTK applications

GUI front end for synaptics touchpad controls.

FLTK ALSA Mixer front end.


I've yet to find a FLTK based editor I really like. For now, I'm still using SciTE, Fxite and nano.

I would love to find a Scintilla based FLTK editor. The closest I've found is https://github.com/cyantreeguo/Fl_Scintilla

There are many FLTK editor controls out there, including the one used by Postoffice.

Nanolinux offers flwriter.

The most interesting editor option I've found so far is fldev. There's a link to the original at http://www.fltk.org/wiki.php?V235+TC+Q and further development by the developer of NanoLinux at https://sourceforge.net/projects/fldev/ The main drawback is that it only opens one file at a time. The original author began to add support to use it as a debugger in conjunction with gdb. I'd love to get that support working properly and in a cross-platform manner and have been experimenting with it as time allows.

flabc is an editor specifically designed for ABC notation, but it appears to be a stable, well-written editor and may be useful for other editing purposes.
While libSDL is typically used for games, there are some applications that can be used to replace common desktop and productivity applications. I'll list the ones I've found here. If you have other alternatives, please let me know.

I've been working on simplifying the applications I typically use on Linux so that they can run in framebuffer mode using DirectFB or Nano-x instead or requiring X Windows. I'm always looking for portable applications, so I can run them on any system I'm using (at home or at work) whether it's Linux or FreeBSD or Windows or something else. I'd love to hear from others with similar goals.

The list just covers libSDL applications. They all built with SDL 1.2.x and I'm creating or locating ports to SDL 2.x as well. I haven't listed SDL based applications that use PDCurses or OpenGL/TinyGL. There are enough of those to warrant their own lists. More information on SDL applications and other screen libraries is available at: http://www.distasis.com/cpp/scrlib.htm#sdl I've posted some of the patches/build scripts for my SDL 2.x ports and will add more over time. You can find them from the archive link at: http://www.distasis.com/cpp/lmbld.htm

URLs are accurate as of when this was posted. However, they can change over time. You can use a search engine or archive.org wayback tool to find pages that have been moved or backups of older versions of pages.

Font viewers:

Good for picking what font you want to work with quickly.

Let's you see all the characters in the font, so you can check if there's support for specific characters needed for internationalization.

Epub reader:

Includes text to speech capabilities using Festival Lite.

Word Processors:

There are a series of SDL based text editors that use a core of common code with some variations in order to port to various handheld devices. Tried building and running, but it's hard to work with since it expects an on screen keyboard rather than a real physical keyboard.

File Manager:

Completely SDL based, two pane file manager.


Lightweight, fast graphics viewer.

Slideshow viewer.

Graphics editor.

Older SVG library. Includes a simple SVG viewer.

Supports SVG rendering and is not tied to a particular screen library. I built a simple SDL SVG viewer with it. If you're looking for SVG support for SDL, this is the best option I've found to date.




Tuxpaint and lunapaint are also SDL options for graphics editors, but I'm not currently using either of them.


Mod player. Can also create music.

The project has a simple, lightweight wave file viewer. I added support so that it works with SDL in place of some of the other graphics options it used.

Sample audio applications.

AV players:



Unfortunately no one's added sound support yet.













July 2017

234 5678


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 20th, 2017 12:41 pm
Powered by Dreamwidth Studios