Developer page for selecting a widget-set for OtherTuningSoftware/NintendoGameBoy

[(most) complete exhaustive list of widgetsets]

Note that since we need significant functionality for any tuningsoftware, we have 2 options:

So we have to find a lightweight API, technically and licencewise useful implementation that abstracts the graphical and user-input HW. We must write the tuningsoftware against this API. normally this is actually 2 layers:

We need to select the widget set, and the graphical primitives layer is just needed to make it work.

API requirements

API wishes

Possible options for widget-sets follow. (google: design GUI control embedded lightweight)

Don't miss the [review of options] - about 6..8 toolkits. wxWidgets (see below) has a good comparison page.

Maybe only last 3 is competing:


SDL - Simple DirectMedia? Layer

GGI and SDL seem to be the most widely used API-s on linux. Lightweight. I didn't see usage inside win32 window, but should be possible the same way as in x11 window.


For now (without trying prototype for either one), my vote is to check microwindows first.

We still have to choose between 2 APIs:

Unfortunately GPL (not LGPL).

Footprint: on 16 bit systems, the entire system, including screen, mouse and keyboard drivers runs in less than 64k. On 32-bit systems, support includes proportional fonts and applications are typically less than 100k. (note: my guess is that's flash; and RAM usage depends heavily on app)

It seems to provide more functionality than GGI or SDL. (note: I read that SDL is being ported to microwindows? does this makes sense?)


Unfortunately it's GPL, not LGPL. Apparently closed development, but sometimes they release the old version as GPL. Registration required to download old source.

Microwindows seems to be better.


I'm not even sure that this is suitable.


Although this would provide exactly the desired functionality, memory footprint probably rules it out.



GTK/GDK/Glib memory footprint seems to rule it out for Nintendo. X11 is out of the question. Note that it performs bad even on win32. Dave Andruczyk MegaTunix author said that most performance problems come from pango library, that are unlikely to get fixed soon.

It's not worth to consider porting GTK/GDK/Glib/GLADE to 256kbyte RAM and framebuffer. The question is if it's already done.

GTK+/fb - from [article]: The stripped, shared GtkFB? libraries occupy about 2 MB of disk space. Additionally FreeType? is 202KB, libjpeg is 138KB, libpng 126KB, libz (needed by libpng) 58KB. The flash footprint would be acceptable, but I bet that RAM usage would be beyond 256kybte.


With static linking we can be sure only the required code is included. Still much redundant stuff left: internal code that handles overlapping windows, themes, true-type fonts (that we don't strictly need). Pixmap handling (via XPM is inefficient).

Even with GTK, the reuse of MegaTunix code seems problematic.


Strong widget-set on Linux and win32. KDE and Opera were written with QT (though not QT-embedded)


seems similar to GTK. Definitely more suited to embedded environment. [an article that likes it]


[wxWidget comparison to other toolkits]

Very suitable for both PC apps (win32 or linux, eg. [codeblocks] and audacity were written with it) and embedded development