Table of Contents:
To the main page.
One way to find cross-platform applications is to find out which programs use a cross-platform GUI or screen library. Although some programs may use these libraries and not compile on other operating systems, you'll still find many cross-platform applications this way.
There are several ways to break up applications. I've used functional categories on my Lightweight and Cross-Platform Open Source Software page such as writing, multimedia and so on. Another way to examine them is by what libraries they require to run. While this probably doesn't matter much on Windows where you're used to having a program install with everything it needs to work, it can be highly useful on low resource POSIX machines (Linux, FreeBSD, etc.) or even on a portable drive device like a USB flash drive. Planning what shared libraries you need and can reuse on your machine can help save resources. GUI libraries can be one of the worst resource hogs, so I wanted to share information on some of the GUI libraries out there and mention some of the programs that work with each. Many GUI libraries also have more comprehensive listings of applications you can use with them at their web sites.
You can find further information on pros and cons of various screen libraries at the page describing My Ideal Open Source Distribution
I use PDCurses whenever I need a curses library on Windows (or DOS). It compiles and builds on Linux as well using X Windows. There's also a newer build option for SDL. I think it looks a little nicer than the X version (and it's also easier to compile). If you have Framebuffer support working on your Linux system and have compiled SDL with support for the framebuffer or using DirectFB, you can run the PDCurses based programs in Framebuffer mode without X. I'm currently working on an option to use SDL2 as well as SDL. It adds better Unicode support and uses SDL_ttf or SDL2_ttf for font rendering. Most Linux applications that use curses for a screen library usually use ncurses. At one point, PDCurses was the only option for Windows users. However, like PDCurses that works well cross-platform on a variety of operating systems, ncurses has branched out to add some support for Windows systems. I can't help wondering how many programs created specifically for ncurses will compile with PDCurses instead. There's also a Windows based port/fork of PDCurses that runs as a standard Windows program instead of in console mode. PDCurses has some limited UTF-8 support and the Windows version boasts internationalization support. However, the SDL based version of PDCurses uses a hard-coded character set and has no UTF-8 or internationalization support. I read about some plans to use SDL_ttf and add UTF-8 support, but there doesn't appear to be active development on it at this time. As mentioned, I'm adding SDL2_ttf support and while I'm at it I'm backporting the changes to SDL and SDL_ttf. If anyone else is interested, feel free to contact me.
Timidity is one program that has a curses interface (along with other interfaces) on both POSIX machines and Windows. It specifically uses PDCurses on Windows and ncurses on the POSIX side. I've run across quite a few programs that work using the curses library to draw on the screen. Cross-platform programs include lynx (doslynx), mc, nano, gramofile, dialog, wordgrinder, hunspell, ncurses hexedit, gdb tui. POSIX only programs include naim, nrss, umix, calcurse. There's also pwsafe (or PasswordSafe for a Windows version). Textadept has a curses interface (as well as others) and uses the Scintilla editor that SciTe is based on. It's an interesting alternative to editors like nano, vim and emacs. Some programs run on Windows if built with Cygwin and using the Cygwin dlls. These include alpine (with pico) and tin. Plus there's an updated version of alpine called re-alpine.
Pros: Both pdcurses and ncurses are efficient, lightweight and cross-platform. Doesn't require the overhead of X Windows. It's a C library for those who prefer the efficiency and portability of C.
Cons: Some people (not me) don't like the look of console applications or think it looks too old-fashioned. Limited internationalization support in some cases.
SDL stands for Simple DirectMedia Layer. There are two main versions of it, the 1.2.x version and the 2.x version. Although there's a lot of active development on the 2.x version, most applications I've come across that are of interest to me were designed for 1.2.x. There is no portability layer to make 1.2.x based programs work with 2.x libraries at this time. However, many of the utility libraries used with SDL, such as SDL_TTF, SDL_Mixer, SDL_Image have ports for SDL 2.x. Both versions support building on a wide variety of platforms, but the platforms differ for each version. The newer version seems to have more emphasis on hardware acceleration and mobile device support.
While I haven't seen many applications other than basic SDL libraries get ported to SDL 2.x, I've been investigating how difficult it is to do so myself. That way, all my applications can work on one version of the library. Once I worked out a few issues, it didn't seem too hard to port between the two versions. I'm currently working on porting the SDL 1.2.x applications I frequently use so that they'll work on either version of SDL. As mentioned, I'm already working on PDCurses. I'm also looking into an X11 compatibility layer (similar to NX11 library) based on SDL. That way, I can more easily port applications like xfireworks off X Windows and use it on more platforms. If anyone's interested, feel free to e-mail about the project.
Dosbox is a good example of a program that requires SDL. There are a lot of programs that will build with SDL. I had hoped to find some more general purpose or utility programs. I have not found much of them for this library. It's used more for graphics and entertainment applications. On Linux, if your machine supports Framebuffer, SDL can be built to make use of it or it can be built to work with DirectFB. If Framebuffer support is available for your hardware, you never need to use X with it. You can also build applications to support multiple backends. The same application could work using X11 in X Windows or using the Framebuffer at a console. Dosbox, Perigee slideshow, picaxo (there's a Cygwin version for Windows plus I have a Windows port with a few extra features), hyperlist, photocrop 0.2, xtopng 0.3, nightsky, sfontview, unifont and PDCurses work fine with it. Bard Storyteller is a very impressive yet minimal epub and HTML reader with text to speech capability based on SDL and flite. There's a nice SDL example screen program called stars that displays stars on the screen. I ran across a nice waveform viewer program designed for some older graphics libraries which I ported to SDL. Fische is a visualization tool which can create nice effects while one's listening to music. TuxPaint uses SDL plus some helper SDL libraries like SDL_ttf. Two other useful graphics editors for SDL are grafx2 and lunapaint. Video programs like mplayer and vlc that offer non-X versions often use SDL to help with rendering. I've found some ultra-lightweight video players for SDL, flxplay (for flx, flc files), theoraplay (for Ogg Theora files), webm-player (for webm files, unfortunately no sound support) and playvpx (for vpx files, although I have no vpx files to test it with). Green allows viewing of PDFs in Framebuffer mode on Linux thanks to SDL (but still requires GTK+ libraries). I'm working on a purely SDL based front-end for mupdf. If you can't use libsvga with your machine, but Framebuffer mode works with directfb, you can theoretically, compile zgv to use SDL with Framebuffer for displaying graphics outside of X. There's even a way to emulate parts of Mesa or OpenGL using one of the forks based on TinyGL (such as TinySDGL or PicoGL). I'm currently using PicoGL for some basic OpenGL graphic examples and I've added some functionality from the other forks as well as some code of my own. I now have Emilia pinball working with SDL and PicoGL instead of OpenGL. When I packaged picaxo for Vector Linux, someone complained it didn't fit his screen properly. I hadn't tried using it on large graphics since I mainly use it for bringing up small graphics to preview quickly. Personally, I like the program a lot, but to increase its appeal a bit, I've added a patch that uses the SDL_gfx to shrink the graphic if it would otherwise be too big to fit on screen. I've also successfully built it on Windows without Cygwin or X.
SDL worked fine with framebuffer support right out of the box with Debian Squeeze. I've since built SDL from source on Debian and I find it less buggy to use DirectFB than the framebuffer driver. Some applications just crashed but worked fine if DirectFB were added to the mix. I attempted building SDL on FreeBSD using various console libraries so that I could run SDL applications outside of X Windows. I tried building SDL with VGL and libsvga. There's also the directfb option, but on FreeBSD it uses SDL to build, so it's probably a recursive waste of time. I had no luck getting SDL based applications to run without X Windows, even when I tried changing the SDL environment variable setting for SDL_VIDEODRIVER. I attempted to debug the issue further on the SDL mailing list, but didn't get anywhere. If there's a trick to running SDL applications without X Windows on FreeBSD, I haven't found it yet. I've since talked to the developer of Rogue Class Linux. He mentioned that SDL support for framebuffer on BSD is not very good and said he might look into working on it at some point.
I've also been searching for some good control or widget libraries to use with SDL. There are several GUI libraries for SDL, but most are oriented toward gaming needs. Two that look nice and are highly portable are guichan and sdlwidgets. I hear agar mentioned a lot, but it can also be tricky to use. CEGUI offers a lot of functionality but with that functionality comes some complexity. I've seen ParaGUI recommended, but didn't have any luck building it on Windows. Since PDCurses can be built with SDL, it can be used as an interface and any curses based libraries that port to PDCurses will work with it as well. I've seen a few applications that take advantage of SDL for drawing and PDCurses for UI display. I'm looking into using SDL with PDCurses to create a new, portable mupdf front end. There's also a SVG library for SDL, but the drawings don't always appear proportional.
Pros: Highly portable. Doesn't require the overhead of X Windows. It's a C library for those who prefer the efficiency and portability of C.
Cons: More for graphics and video than GUI support.
OpenGL and the Open Source equivalent, Mesa, are libraries that are mainly used for Graphics. Some programs use OpenGL purely as their interface. One can also draw to a buffer using OpenGL and then use another library to blit the results to the screen. Other applications use OpenGL with SDL or UI libraries in combination. XBMC is one example of this. However, on Windows it uses the DirectX interface even though SDL and Mesa are both portable. Celestia is a good example of an application that uses OpenGL and Glut for an interface. Ssystem and Openuniverse are similar to Celestia but older. They're not current projects, but they can be less resource intensive than Celestia on older hardware and might be worth a try if Celestia won't run. Gliv uses GTK+ and OpenGL libraries and provides a nice image viewer. I've been looking for some other OpenGL implementations besides the standard Windows one available and Mesa. As mentioned, there are several forks of TinyGL with limited OpenGL support. I found an alternative implementation for Windows, but haven't experimented with it. I'm still looking for other portable options but, so far, I like my modified version of PicoGL as a simple, light-weight, portable alternative to Mesa.
FLTK is a lightweight cross-platform GUI library. It builds fine on Windows, FreeBSD and most versions of Linux. Deli Linux required a few patches to version 1.9.1 because of the non-standard uclibc library. The problem is also possibly a good example of why there were so many forks of FLTK. The developers tend to be slow to accept patches if they accept them at all (which they wouldn't in the case of uclibc support). Several versions of FLTK were forked to add UTF-8 support. Version 1.3.x has minimal UTF-8 support and most 1.x based programs work with it or will port to it. Version FLTK 2 is no longer being worked on and is supposed to someday be replaced by version 3 which will support 1.3.x applications and version 2 applications. Version 3 is not being actively developed at this time and a wide variety of applications work with the 1.3.x line, so it's the most logical version set to work with if you want to develop applications using FLTK. While programs like dillo originally chose FLTK 2 over FLTK 1.x for UTF-8, most active programs have since switched back to using 1.3.x over 2. Equinox Desktop Environment which was using a fork of FLTK is now using FLTK 1.3.x plus an extra library. Most FLTK 1.x applications can be ported to 1.3.3 and many have already been ported. There's new application development for distributions like NanoLinux and Tiny Core Linux. Gleam theme has been incorporated into FLTK 1.3.3. The oxy theme, which is very nice, is still only available in patches. It's too bad they haven't been integrated into the official FLTK 1.3.3 release. I use the patches with all my FLTK builds. FLTK can be built on Windows, POSIX systems with X11 and Nano-X systems using nxlib. I had lots of issues building it for X11 natively on Windows, but if one is using Cygwin where _WIN32 isn't defined by the compiler, it seems to work okay. FLTK built with Nano-X means it will works on any systems that can run Nano-X, including DOS. There was a port of an older version of FLTK to DirectFB. I'm looking to see how much of it will transfer to 1.3.3.
I've tried out the programs flxine-0.6.1, fldiff-1.1, flphoto-1.3.1, mfm-0.4, prozgui-2.0.2, fltdj 0.7, flrec 0.12, xdiskusage 1.48 and tux_todo on Deli Linux and they run nicely using FLTK. I tried rebuilding mfm, a lightweight file manager, on another distribution of Linux and it had some issues. Either it didn't like that my hard drives were formatted for Reiser at the time or I missed some screen fonts it really wanted to use. I've also had some issues with flphoto and later versions of libpng. PNG files won't draw properly unless you use the built-in libpng support that comes with FLTK. Using the external library causes issues with rendering. Be sure to check the FLTK examples directory when you build FLTK. You'll find some nice programs there, like blocks, checkers and sudoku. Another useful FLTK program is alsamixergui. There's a calculator written using FLTK called mbasecalc which runs on Windows, Linux, BSD and Mac machines. Also, check out flcalc, another useful FLTK based calculator. There are now more than three browsers that work with FLTK, one is Dillo. Another was a Dillo fork but it's been almost completely written and is highly portable. It's called D+ (or Dillo-win32 in its previous incarnation) and it works on DOS, Windows, BSD and Linux. You'll find it in XFDOS and NanoLinux. The developer of NanoLinux is currently work on a fork of the Webkit based Dorothy browser (called wkccc) that will work with FLTK. The new web browser is called Netrider. I did some work on porting it to Windows. A new version of Netrider is in the works that uses another version of webkit. One of the TinyCore Linux developers is working on another port of webkit (using yet another version). There's a browser project based on it that is working on an Opera like browser. Of all the various webkit ports, wkccc seems to be the easiest to build, the lightest and the most portable. It works with FLTK, SDL or other user interfaces or even command line applications. Dependencies include Google's skia library for graphics rendering (instead of other options like Cairo, Qt, etc.) and curl for Internet access (instead of options like libsoup.gnutls). At one point cinepaint was going to use FLTK 2, but they switched to 1.1.10. Only Cinepaint Glasgow works exclusively with FLTK. Later versions of Cinepaint use a combination of GTK+ and FLTK. I was able to get flphoto, fldiff, fltdj, mbasecalc, flcalc, flpicsee, photoColoring, xdiskusage, prozilla plus all the FLTK library demo programs working on Windows. Other programs worth checking out are fltkmm and wordsearch. flysynclient looks useful for POSIX systems. For a password database, check out fpwdman. The developer of NanoLinux has updated the fldev IDE program to work with FLTK 1.3.2 and added some features. It's available at SourceForge. I noticed another developer has updated flxine, but I haven't had time to check out the changes yet. I'm still trying to port flxine to Windows. Someone's working on a FLTK front end for vlc called flvlc. Rendera is a lightweight graphics editor. I've been able to get apcstudio to build with some patches and it makes an interesting audio editor. Still working on adding some features to it. It took quite a while, but I finally got postoffice to build. It needs a lot of work, but it looks like a nice simple e-mail client. If anyone's interested in helping to get it working again, let me know. NanoLinux has flmail, another FLTK based e-mail client and an IRC program, flchat.
Pros: Lightweight compared to most other GUI libraries. Some UTF-8 support. Has some themes. Somewhat portable. There were several forks and I've seen many people complain about that. However, most FLTK applications have been ported to 1.3.x (if you know where to find them) or will easily port to it.
Cons: It's a C++ library. Some C aficionados prefer pure C GUIs. Theme capability is hard-coded unless a third party library is used, thus making it hard to get anything other than a standard look. Some people don't like the look of the applications, but I happen to like it better than several other GUIs out there. Don't expect support for systems like Wayland any time soon. (However, if a port DirectFB works that might provide a viable X alternative.) Developers are slow to take patches for various platforms and may take some and leave others.
Fox Toolkit comes with some smaller Linux distributions, so you may not have to install it. They typically use it as a lighter desktop alternative. Most programs I've seen are built for Fox Toolkit 1.6 which does not have internationalization support. Some programs with active development are using 1.7 which does have some internationalization support. While there are a lot of interesting Fox Toolkit applications out there, many are no longer under active development and most have not been updated to and will not work with 1.7 as is. It's also getting hard to find the source code for older projects.
Fox Toolkit itself, comes with a lot of useful example programs, like shutterbug (a screen capture program), adie (an editor) and Pathfinder (a file manager). The library is cross-platform, so all the example programs run on Linux and Windows. Programs that use this GUI library on Linux and FreeBSD include xfe (another nice file manager), goggles (ogle DVD player front end, no longer developed), gogglesmm (Googles Music Manager), fxdesktop and rezound. Fxite is a lightweight programming editor based on the Scintilla editor that SciTE uses. It has active development. If you want a faster, more lightweight GUI programming editor, this is definitely worth checking out. dxirc is another Fox Toolkit application that's being actively developed.
Pros: Heavier than FLTK but still lightweight compared to most other GUI libraries. Some UTF-8 support. Somewhat portable.
Cons: It's a C++ library. Some C aficionados prefer pure C GUIs. No theme capability. Some people complain they don't like the look of applications. I personally don't mind but it depends on one's taste. I did find key handling a little disturbing with menus, but I have a patch I wrote to make it more CUA compliant. Can't find that many active projects currently using it.
There are programs that work with X Windows directly and don't require large GUI libraries to build. At one point, Motif was poised to be the library for GUI development on X Windows. Lesstif was a port of Motif to Open Source. However, Motif, lesstif and even X itself are not usually the most popular choices for GUI libraries to support cross-platform development. One can port X to other platforms and then other libraries using it may work. For instance, I have X Windows built natively on Windows using MinGW and applications such as xfireworks, dclock and figurine are running with it. However, X applications don't necessarily port easily to Windows. Audio support, POSIX functions (such as fork), differences in headers/libraries (socket functions versus winsock library), defines such as _WIN32 can make it harder to port X applications to Windows. It doesn't mean it can't be done. One can use Cygwin to provide a POSIX emulation layer or one can use Windows natively and port the differences. Cygwin provides X libraries and Xorg server. There is a stand-alone X server on Windows called Xming. I also currently have a native build of Xorg and X libraries using LM BLD scripts. There is a lot of code behind the X distribution. It was designed to work well on networked systems that might not be very efficient, but it handles everything from drawing to communications between networked client/servers. If developing for X Windows is a given, using Motif, lesstif or especially the X libraries directly can provide more lightweight support than some of the larger cross-platform GUI libraries. The developers of X Windows appear to be moving on to creating Wayland. However, Wayland, is currently more Linux specific. While there has been some effort to port it to BSD, it's likely most BSD and Unix systems will continue to use X for several years. Wayland removes a lot of functionality that X Windows provided and lets the Linux kernel and GUI libraries handle many of those tasks.
Lesstif and X Windows programs include aumix (also available using curses and gtk+), dclock, figurine, sunclock, snd, plan, xearth, xclipboard, xpdf, gv, mgv, xwave, xfireworks, xfishtank. Worker is supposed to only require X Windows to run. Timidity has an X Windows compile option. The XAW option (X with Athena Widgets) of Timidity gives you even more functionality such as better lyrics display and piano keyboard display. These need an X server to run. One exception (besides Timidity) is mupdf. There's a version that works on X, but it works very well with Win32 natively on Windows too (using different source code and the same library).
Some alternatives to X are/were Nano-X, tinyxlib, KDrive, XFree86. TinyXlib is an older version of X with some excess code removed. There's been some development to add in newer features from X that might be needed in TinyXlib. XFree86 was an early X Windows implementation that was later forked (supposedly for license reasons) to create the current Xorg fork most systems use. KDrive was an X server that was designed for low memory systems. Some of its code was eventually integrated into the Xorg implementation. There was talk of support for SDL as a backend for KDrive and certain builds of the Xorg server, but it's difficult if not impossible to find working code. Nano-X is a completely new implementation of an X server. Nxlib offers some of the functionality provided by X11 (enough to run some FLTK applications and some X applications). It's much more lightweight than X (much less code) and is used on some embedded systems in place of X. I've noticed less support for hardware than Xorg. Also, with some video cards (such as some ATI cards), colors may display improperly. I'm working on creating a library to ease porting of X applications so they'll continue to work with out an X server and X libraries. The library (sdl_xlib) is currently far along enough to be able to run xfireworks.
Pros: Using just the X library is certainly more lightweight than using a GUI built on the X library. X is made up of mainly C libraries and applications for those who prefer the efficiency and portability of C. Works efficiently over networks. Has client/server support. You could run an application on a Raspberry Pi and view it on another monitor that the device is networked with or send intranet messages to other machines.
Cons: Requires several libraries, headers, drivers to build and run X. Not as lightweight as Framebuffer options.
The wxWidgets library works on a wide variety of platforms. It runs on Windows using the Win32 library. However, on Linux and BSD systems, it's usually built on top of the GTK+ libraries. In order to reach the embedded and handheld devices market, there's some work going on to port wxWidgets directly to X and to DirectFB so it can work in Framebuffer mode without X. I've tried some of these ports including using it with X directly, but was unable to get anything that I tried to build to run. A lot of my favorite Windows programs compile on Linux with wxWidgets (and GTK). These includes Audacity, Filezilla and DVDStyler. On DeLi Linux when building DVDStyler, I used version 2.6 of wxWidgets since I was having trouble building the latest version. You may have to use older versions of a program if you're using an older version of the library. The good news is that version 1.4 of DVDStyler (my favorite version) runs with version 2.6 of wxWidgets. When I tried Absolute Linux it came with version 2.8.7 installed. The bad news is DVDStyler 1.4 does not run with it. You'll need a later version. DVDStyler changed the style of vector graphics it was using when it switched from netpbm to the wxSVG library. Unfortunately, that means any setup files you created with 1.4 or earlier versions are not compatible with later versions. I have patches to get Comical to build with later versions of wxWidgets. Some operating systems such as FreeBSD have the annoying option of building half the programs I use with this library with the Unicode version and half without. At this point, I'd prefer to use the Unicode version on my system. If I want to use all my favorite wxWidgets based programs, I have to rebuild from source (and scratch) the ones that have ports created to use the non-Unicode version instead of the Unicode version.
Pros: If you're running on Windows, it's more lightweight than GUI libraries like GTK+ and Qt. Somewhat portable.
Cons: If you're running on X (POSIX systems), you need GTK+. This makes it heavier than most other GUI libraries. Embedded ports don't seem to work for the applications I need.
QT is one of the larger cross-platform user interface libraries that also provides support for features such as internationalization. One program I hate to do without that requires QT is wkhtmltopdf. Wkhtmltopdf uses a patched Qt 4 library to add some extra functionality. I'm happy to add there is work going on to include Qt 5 support for wkhtmltopdf. A program like html2ps could be used instead, but wkhtmltopdf has much better support for later versions of HTML and CSS. It works on both Windows and POSIX machines and if you can get the QT patched version, it offers useful added functionality. If you're running Qt 4, you might also find keepassx, speedcrunch, scantailor and fbreader useful. A rewrite of searchmonkey is being done with Qt 4. Nocam is a grapics viewer for Qt. Several web browsers are available for Qt 4 including arora, qtweb, webrender and lightbrowser2 and a browser demo program that comes with Qt itself. Other programs that use Qt 4 like qmmp, qcomicbook are available mainly for POSIX systems. Though, I've seen a port of an older version of qmmp to Windows. There's a qtconfig program for customizing the look and feel of Qt applications.
LXDE-Qt/RazorQt and the various programs associated with these projects are being targeted for some version of Qt 5. Many programs are updating to the latest version of Qt (including wkhtmltopdf and PhantomJS). There's supposed to be better support for X11 alternatives like Wayland in Qt 5. I'm still attempting to get a successful build of Qt 5 on Windows using MinGW and msys. (Actually, I have libraries building at present, but not the QtWebkit piece.) If anyone has any tips, please let me know.
Pros: Portable. Has internationalization support. Supports themes. Has built in support for webkit.
Cons: Not the most lightweight and can take quite a while to build from source. If not build in the directory it's meant to be installed in, one needs to set up a file to indicate where libraries and needed files are. Documentation on how to build on some systems is scarce or non-existent. It's a C++ library. Some C aficionados prefer pure C GUIs.
I attempted to build GTK+ 3 on Windows. Their web page http://developer.gnome.org/glib/2.30/glib-resources.html encourages people to file bug reports. It says "Don't hesitate to file a bug report, even if you think we may know about it already, or aren't sure of the details." However, in reality, they seem anything but friendly toward certain issues (such as cross-platform building issues) being reported. I don't mind working and creating patches for projects that offer no support, but I draw the line at getting involved with projects that are hostile towards developers' issues. At this point, I highly recommend using OTHER GUI libraries in place of GTK+. Obviously there are others that feel that way too. Just look at projects like LXDE or Searchmonkey. I am investigating replacing the programs I use that are built with GTK+ with other Open Source alternatives from more user and developer friendly projects.
GTK+ is also cross-platform portable. In order for Gimp to work properly on Windows, GTK+ was ported right along with it. There are several programs that work with the GTK+ libraries. Some older ones use the GTK+ 1 versions of the libraries which have a different API than the later GTK+ 2 versions. However, most programs that were actively maintained were updated to the GTK+ 2 libraries. There are also some tricks to gain some backward compatibility when attempting to build GTK+ 1 applications with GTK+ 2. GTK+ 3 is now available and most programs are once again porting to it. From the documentation, porting GTK+ 2 programs to GTK+ 3 probably will be as feasible as porting GTK+ 1 to GTK+ 2. However, older GTK+ 1 programs may lack support and require a complete rewrite in GTK+ 3. GTK+ is another of the large, cross-platform libraries that supports features such as internationalization. It also supports customization of the look and feel of applications using it. Both switch2 (gtk-theme-switch 2) and gtkchtheme let you change theme preferences and set up your system. There's a program to change themes on Windows too. GTK+ 3 uses CSS for customization. GTK+ 3 will have support for Wayland. GTK+ isn't small (especially the later versions), but since so many programs run using it, most Linux distributions install it or give you an option to. I've seen the glib library from GTK+ infiltrate non-GTK+ programs like console applications and even Qt offers support for glib. sdcv is an example of a command line program that uses glib. (I have a port that doesn't require the glib dependency and works on POSIX and Windows systems.) Glib provides the core application building blocks and I see it as a sort of portability layer over the POSIX C library. I've read complaints about glib and efficiency from developers on some of the alternative C library mailing lists.
There are plenty of programs that work with some version of GTK+ (and possibly more than one version at some point). Some of the programs for POSIX systems include XCDRoast (older versions work with lesstif), Asunder, Gentoo (file manager), any of the wxWidgets based applications, gopchop, ePDFView, mhwaveedit, sweep, audacious, fotoxx, gpicview, geeqie (fork of gqview), viewnior, gperiodic, emelfm2, lxtask, gtklp, usermode, hardinfo, wmfishtime (with patch). Nathive, obtheme and lusers are written in Python, but still use GTK+ 2 libraries. Gscan2pdf is written in Perl and uses GTK+ 2 libraries. GTKdialog uses GTK+ as well. There are several wonderful GPE applications that work not only on handheld devices but, in many cases, on POSIX systems in general. These include programs like gpe-appmgr, gpe-calendar, gpe-shield, gpe-gallery, gpe-mixer, gpe-screenshot, gpe-soundbite, gpe-todo and others. The gpe applications are designed nicely and work well together. Some cross-platform GTK+ 2 applications are sdcv (command line but uses glib), stardict, spkg, SciTE, Sylpheed, sodipodi, mtpaint, neonview, evince, fbreader, starplot, snd, xdialog, gxmessage, yad. There's also vmg (Virtual Magnifying Glass) written using FreePascal and GTK+ 2. There's a port of gqview to Windows called qgview-win. SciTE is currently being updated to support both GTK+ 2 and GTK+ 3 and I assume other active projects are doing likewise or switching to other toolkits (like LXDE-qt and Searchmonkey did).
Pros: Portable. Has internationalization support. Supports themes. Lots of applications available that use it. Mostly C libraries for those who prefer the efficiency and portability of C.
Cons: Not the most lightweight and can take quite a while to build from source. Developers I had contact with did not seem too friendly about supporting platforms other than the ones they favored and were not at all willing to accept patches for them.
I haven't seen any applications I want to run that use Enlightenment. However, someone in a Linux Users Group recommended Enlightenment as a well designed cross-platform library. So, I decided to try it out. My impressions did not confirm the recommendation. It does work on several platforms and it can be ported, but the developers are very specific about what platforms they support and they are not open to taking patches to make it work out of the box on any platforms they do not have interest in. To me, that's not what to look for in a cross-platform library. I haven't seen a lot of well-known applications that use the library and I personally don't use any. If you're looking for a cross-platform library, I'd recommend looking elsewhere.
Cons: Not a lot of useful applications available for it. Developers I had contact with did not seem too friendly about supporting platforms other than the ones they favored and were not willing to accept patches for them.
To the main page.