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:
- write the widget set or
- use an existing widget set (and optionally tweak it a little, rip parts)
- strongly biased towards using existing code, since we want to develop tuning software, not widget-set (or windowing system).
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:
- widget-set API like GTK, Qt/embedded or FLTK
- graphical primitives API like win32-API or GDK or X11 or framebuffer
We need to select the widget set, and the graphical primitives layer is just needed to make it work.
API requirements
- easily usable on win32 (apparently always holds)
- easily usable on linux (apparantly always holds)
- portable to bare-bone framebuffer (eg. GBA, or VEMS-rolled ARM-based display that only has framebuffer, not X11 or tiny-x or similar)
- preferrably fits in 4 Mbyte flash footprint
- and 256 kbyte RAM (with 240x160x8bit display size. More RAM available with bigger display. 256kbyte RAM enables OtherTuningSoftware/NintendoGameBoy (GBA). (well: GTK is out at this point)
- OtherTuningSoftware/GoodAndBadTuningSoftware specifies how the tuningsoftware will be used:
- easy stepping over pictures (icons) via keyboard, not too deep menus
- mouse is not required (but supported, where available)
API wishes
- portability to winCE, winSE and small footprint linux PDA would be nice too
- LGPL or similar license preferred (LGPL strongly preferred, because LGPL enables us to choose license while a GPL library forces us to apply GPL without any option)
- audio ?
- called "GTK" :-) This would make MegaTunix porting simpler. Probably conflicts with footprint requirement though
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:
- wxWidgets
- Qt
- FLTK
GGI
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.
Microwindows
For now (without trying prototype for either one), my vote is to check microwindows first.
We still have to choose between 2 APIs:
- the Nano-X API: this was my first thought. Allows more than one app on microwindows, but IMHO we don't need this functionality now
- the win32 API (subset). after rethinking, this API can be better choice than it seemed first: might enable running our app directly on win32 or wine (x11), without microwindows. Both for development and production.
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?)
Minigui
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.
Dropped
- [Espial UI toolkit] bad license
- [OpenGUI] is x86 only
GTK
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.
GTK+/Microwindows.
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]
wxWidgets
[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