GUI library design

Some of the C graphics libraries are great, but I've yet to find a simple GUI that makes it easy to port some older BASIC programs that I want to be able to keep working with. I've created several iterations of my own GUI library, but have never been satisfied with the results. That's the main reason I keep investigating cross-platform GUIs, to see if someone's found a better way to do it. Of the various designs, the ideas behind the immediate mode GUIs seem the most useful for the type of programs I'm targeting. However, I can't seem to find one GUI library that provides a simple way to do what I want. So, I've decided to revisit my old GUI library designs but eliminate some of the framework constraints and some of the object oriented elements. Instead, I'm looking at a more procedural approach that uses concepts from immediate mode GUIs.

Even though I'm avoiding popular C/C++ GUI libraries, I'm not starting completely from scratch and writing everything myself. There are plenty of good graphics libraries that are very portable and make a great basic starting point for a GUI. One of the libraries I've been very impressed with is SDL. It makes a great base for porting software. I've also done a lot of work with PicoGL (a TinyGL fork). It's a convenient way to make OpenGL more portable and avoid some of the version issues. It works on low resource platforms such as handheld devices that don't have high performance video driver support. I've often found OpenGL and Mesa slow on older computers and low resource systems. PicoGL provides very good performance on these types of systems. While using Win32 is not as portable as I would like, it's not that hard to get an OpenGL window up and running on Win32. That easily allows switching between Win32/OpenGL and SDL (1.2.15 or SDL 2.x)/PicoGL. SDL can work on a variety of platforms and PicoGL can work with SDL or with other options such as nano-x, X11 or vesa framebuffer. It shouldn't be too hard to take the output from PicoGL to use with the Android bitmap API either. Another possible option for a backend is Allegro. Like SDL, it works on a variety of platforms. It would be nice to switch between SDL and Allegro as backends depending on which works best for a particular platform without needing to redesign an entire application.

The PDCurses/ncurses API provides a standard way to create console based programs that work well on a variety of platforms from DOS to Windows to FreeBSD to Linux. However, it provides only text support and no real graphics support. While it's great for porting programs written to work with it, I don't think it's the best option to use as a GUI backend. I recently came across TinyCurses which provides a subset of the API and uses SDL as a backend. PDCurses also offers SDL as a backend option. I couldn't help thinking, once a decent GUI design was finalized, it wouldn't be too hard to provide a subset of functionality similar to PDCurses/ncurses. That would allow for easy porting of some PDCurses/ncurses based applications to any platform the GUI library works on.

So, why not just use OpenGL as the backend to design a GUI library? After considering the pros and cons, I decided I don't want to be tied specifically to OpenGL as an API for 2D graphics. While it's very popular and available on several platforms, the changes from a fixed function pipeline to a programmable pipeline with its own shading language make it hard to port programs from one version to another. PicoGL makes use of old fixed function pipeline concepts. Windows OpenGL also uses the older design. Mobile devices and WebGL make use of the newer concepts and the ability to harness the GPU to do more processing. Many developers seem to be abandoning the older concepts and embracing the new programmable pipeline design. However, that leaves some nice older applications that were designed for earlier versions of OpenGL that won't port easily to the newer versions. They might require a complete redesign and rewrite. Using PicoGL is one way to make it easier to port such applications. It can do software rendering to a bitmap which can then use more modern methods (including later versions of OpenGL or SDL 2.x) to transfer the bitmap to the screen. While the idea of using OpenGL as the portable backend for a GUI library sounds good, dealing with version differences and what versions may be available on which platforms does not make it the best option for a complete cross-platform portable solution. Instead, I prefer the concept of being able to switch out backends to use what works well on a particular platform. The GUI library should encapsulate the rendering as much as possible to avoid needing to rewrite applications in order to switch to another backend.

On the other hand, many GUI libraries and some other rendering libraries (such as SDL) offer ways to interoperate with a graphics library like OpenGL. While I want my GUI library code to be cross-platform, I don't want to limit a developer to using just that API. If a programmer wants to use OpenGL or SDL2_gfx or some other library to handle 2D/3D graphics, I'd like the GUI to be able to interoperate with that choice. It would mean that the resulting application would be less portable. However, if an application is already designed to utilize SDL2_gfx, OpenGL or some other library that could work compatibly with the GUI library, it could make adding some GUI functionality to an existing application much easier.

I definitely know what I'm looking for in a cross-platform GUI. I want a simple, portable way to get text, menus, forms, file/directory picker dialog functionality to the screen. I'd like to make use of Freetype fonts. I want an internationalized way to display text and for users to input text. The text strings will probably involve a library such as gettext. I want the options to use keyboard input for those of us who prefer keyboard commands to get their work done and mouse/touchscreen input for devices such as mobile phones where a real keyboard may not be available. I need to be able to access graphics and audio information from a file system or from a zipped file (such as .apk file on Android). I don't care if the look and feel matches what's in style for a particular device or operating system. I just want it to be user-friendly and ergonomically designed.

If you're interested in GUI design or working on a GUI or gaming library of your own, I'd love to compare notes on the subject. Have an idea for what C library might make a good backend for a portable, cross-platform C based GUI? Let me know. Feel free to discuss design issues or other C/C++ topics on the CppDesign mailing list or contact me to compare design notes and share ideas ( http://www.distasis.com/connect.htm ).

TrueType Font Libraries in C

Along the lines of investigating portable C GUI libraries, I started looking at cross-platform library options for font rendering in C. This area is particularly useful if you're investigating creating your own GUI library or game library. I was most interested in the TrueType font rendering libraries and techniques. It was rather surprising to read just how difficult it is to get simple internationalized text to the screen especially using graphics libraries like OpenGL.

Here's what I've located. If you have other recommendations for C font rendering libraries, please let me know.


GUI library options like nuklear and nanovg use stb_truetype.h:
https://github.com/nothings/stb
They also use some kind of font stash, such as this one used with nanovg:
https://github.com/memononen/fontstash


Other GUI libraries use FreeType2.
https://www.freetype.org/

For instance, SDL2_ttf uses FreeType2.
https://www.libsdl.org/projects/SDL_ttf/

Allegro also has font libraries available that are based on FreeType2.
http://opensnc.sourceforge.net/alfont/mirror/

Here's one that works with Allegro or SDL:
http://kirill-kryukov.com/glyph-keeper/files.shtml


There are several font libraries for OpenGL, but there aren't many options written in C. Some are for older versions of OpenGL and some only work with later versions. Here's what I found so far:

https://github.com/rougier/freetype-gl
https://github.com/jtsiomb/libdrawtext
http://quesoglc.sourceforge.net/


Here's another C option that works with FreeType2 and embeds fonts in C programs:
https://github.com/chrisy/fontem


The most recommended technique used by OpenGL developers seems to be texture mapping. A texture can be used like a hash table to store various characters and other pixmaps that need to be rendered. An OpenGL function can draw a piece of the texture or update/change parts of it in memory without affecting performance too much. While software renderers have no real trouble copying or blending a bitmap graphic or pixmap, the newer OpenGL versions send the textures to the GPU for rendering. So utilizing a texture instead of bitmaps/pixmaps and minimizing the number of textures one is working with can improve performance.

I personally find it easier to render text with SDL. It handles copying and blending bitmaps (as an SDL_Surface) and offers a useful library (SDL_ttf) to do most of the work. SDL 2.x does use OpenGL underneath on some platforms, so some of the texture concepts used by OpenGL programmers might improve font rendering performance on some versions of SDL as well.

Freetype seems to be the library for working with TrueType fonts. SDL_ttf uses freetype to interpret the Truetype font format and create bitmaps/pixmaps to represent characters (converting them from vector format to bitmap/pixmap format). I found working with SDL_ttf a lot more user-friendly than trying to use Freetype directly.

Another viable option is stb_truetype.h. The license for this software is definitely an advantage. However, from what I've read the rendering still isn't quite as good as Freetype. I look forward to testing this out on my own at some point.

At this point, I'm still investigating SDL_ttf, stb_truetype.h and OpenGL texture mapping. A combination of these might be just what's needed in a font rendering design for a cross-platform GUI library.

Know of some other font rendering options that work well for Truetype fonts or have a better way to get fonts to the screen, I'd love to hear about it?