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.
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 new build option for SDL. I think it looks a little nicer than the X version. If you have Framebuffer support working and have compiled SDL with DirectFB, you can run the PDCurses based programs in Framebuffer mode without X. Most Linux applications that use curses for a screen library usually use ncurses. I can't help wondering how many programs created specifically for ncurses will compile with PDCurses instead. 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. POSIX only programs include naim, nrss, umix, calcurse. There's also pwsafe (or PasswordSafe for a Windows version). Some programs run on Windows if built with Cygwin and using the Cygwin dlls. These include alpine (with pico) and tin.
Dosbox is a good example of a program that requires SDL. It's also a program I don't want to be without on my machines. There are a lot of programs that will build with SDL. I had hoped to find some more general purpose or utility programs, but there does not seem to be a lot of them for this library. It's used more for graphics and entertainment applications. SDL works with a variety of operating systems and compilers including djgpp for DOS 32 bit applications. On Linux, if your machine supports Framebuffer, SDL can be built with DirectFB and run in Framebuffer mode so you never need to use X with it if Framebuffer support is available for your hardware. Dosbox, Perigee slideshow, picaxo (Cygwin version for Windows), hyperlist, photocrop 0.2, xtopng 0.3, nightsky and PDCurses work fine with it. There's a nice SDL example screen program called stars that displays stars on the screen. 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_Pango and SDL_ttf. Video programs like mplayer and vlc that offer non-X versions often use SDL to help with rendering. Green allows viewing of PDFs in Framebuffer mode on Linux thanks to SDL. If you can't use libsvga with your machine, but Framebuffer mode works with directfb, you can compile zgv to use SDL with Framebuffer for displaying graphics outside of X. There's even a library called TinySDGL that uses SDL and is based on TinyGL. It emulates parts of the Mesa or OpenGL libraries. I wonder if it could be used on low resource systems in place of OpenGL or Mesa?
SDL worked fine with framebuffer support right out of the box with Debian Squeeze. 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 someone knows the trick to running SDL applications without X Windows on FreeBSD, I'd be very interested in hearing about it.
OpenGL and the Open Source equivalent, Mesa, are libraries that are mainly used for Graphics. Some programs use OpenGL purely as their interface. Other applications use OpenGL with SDL or other libraries. 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.
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. 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 doesn't like my hard drives formatted for Reiser or I'm missing some screen fonts it really wants 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. I really like the look and functionality of the FLTK programs I managed to get working with version 1.9.1, but I couldn't help thinking a lot more great programs might be available if there weren't so many forks of this library and if the API was a little more stable. There's already a 1.1.10 version that replaces 1.9.1, but I'm still in the process of rebuilding programs with it yet. You'll need FLTK 2 if you want to build dillo. At one point cinepaint was going to use FLTK 2, but it looks like they're using 1.1.10 now. Of course, FLTK 2 is not backward compatible with 1.9.1 (or even 1.1.10). It also looks like development on FLTK 2 has stalled because of efforts going to version 1.3 (also not backward compatible) which provides Unicode support (which version 1.1.10 based on the 1.1. branch is not supposed to have). One nice feature of FLTK is that it is cross-platform portable. I was able to get flphoto, fldiff, fltdj, mbasecalc plus all the library demo programs working on Windows as well. Cinepaint is available on Windows and Posix machines too. Look for Cinepaint Glasgow if you want the FLTK only version.
Fox Toolkit comes with some smaller Linux distributions, so you may not have to install it. It has a lot of good example programs available with it, 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. Fox Toolkit like FLTK also does not offer a lot of support for internationalization.
There are programs that work with lesstif or 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 best choices for GUI libraries to support cross-platform development. There are other more popular GUI libraries for that. 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. Lesstif and X Windows programs include aumix (also available using curses and gtk+), 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. You probably won't get any of these to work on Windows unless you want to install Cygwin and an X server though. There is a stand-alone X server on Windows called Xming, but you'll still need to compile the X libraries in order to get applications to build on Windows. There have been some attempts to do this directly under MinGW, but the usual route is to use X libraries supplied with Cygwin. One portablity exception is mupdf. There's a version that works on X, but it works very well with Win32 natively on Windows too. Timidity works well on Windows, but it has interfaces written specifically for Windows libraries.
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. 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.
I had not intended to add this GUI library to my machine. I'd intended to use GTK instead, since you can usually find a GTK equivalent application for any program you like that uses Qt. However, if I wanted to run Opera (one of the lightest weight browsers I could find with Javascript and CSS functionality), it comes by default. One drawback to Opera is that it's closed source. If you can get by with chromium, uzbl or other alternatives, that might be a good space saving option. I didn't install full Qt libraries, just the minimum libraries needed by FreeBSD to run Opera. However, since the files were taking up space on my machine, I figured I might as well make use of them by installing some applications that would work with them. One interesting program that uses the same version of the Qt library on FreeBSD is tipograf. It's a GUI front-end for a2ps. There's also MyPasswordSafe which is supposed to be compatible with pwsafe and Windows PasswordSafe. Another program is ecawave. It's no longer being actively maintained, but it's a lightweight audio editor.
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. 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 QT4, you might also find keepassx, speedcrunch, scantailor and fbreader useful. A rewrite of searchmonkey is being done with QT4. 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.
The last GUI library I'll mention is GTK+. I recently 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 on 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+. I will be looking into replacing the programs I use that are built with GTK+ with other Open Source alternatives from more user and developer friendly projects.
It's 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 are currently being maintained have 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 also coming out. 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+ 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. It's 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. Some of the programs that work with GTK+ on POSIX systems are 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. 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, 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.