FLTK is a sensible choice about which I have written previously . FLTK provides most of the widgets and other capabilities needed for GUIs without the bloat and clutter characteristic of many desktop-oriented toolkits. The decision to use a full X implementation rather than FLTK directly on top of the Linux framebuffer is an interesting one. A framebuffer implementation would save some code space at the expense of some flexibility. Thoughts on the compiler Another interesting design decision has concerned the choice of compiler.
Developers are accustomed to the choice of dynamic vs. static library linking.
With static linking all addresses are resolved at link time and the library code used by an application is linked directly with the application itself, so no run time cost is associated with using the library's facilities. With dynamic linking, the library is loaded into memory separately from the application, and the library's functions and variables are exposed in symbolic form. The snow compiler attempts to gain the best of both the static and dynamic linking worlds by resolving symbols at link time but loading the application and libraries separately. Thus libraries can be shared among applications, but the overhead of dynamic linking is saved. The downside is that applications refer to specific locations within the libraries, so the libraries cannot be changed without breaking all the applications to which they are linked.