Developer page for selecting a widget-set for OtherTuningSoftware/NintendoGameBoy
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)
I'm 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 and preferrably (technically and licencewise) useful implementation that abstracts the graphical and user-input HW. We have to 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
We need to select the widget set, and the graphical primitives layer is just needed to make it work.
API requirements
- OtherTuningSoftware/GoodAndBadTuningSoftware specifies how the tuningsoftware will be used: easy stepping over pictures (icons) via keyboard, not too deep menus
- max 256 kbyte RAM and preferrably 4 Mbyte flash footprint (=> enables OtherTuningSoftware/NintendoGameBoy )
- usable on direct framebuffer (GBA)
API wishes
- easily usable on win32
- easily usable on linux
- LGPL or similar license preferred (GPL is acceptable, since intent is make a GPL app; however LGPL would enable us to choose license while using 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, so this "wish" probably dropped
When we choose to work on the GBA we essentially become OS and a widget-set developers to some degree (since the GBA has no OS or widget-set). But we try hard to keep it to a minimum. Minor contribution (of improvements) to the chosen widget-set is OK, of course.
Possible options for widget-sets follow. (google: design GUI control embedded lightweight)
Don't miss the [review of options] - about 6..8 toolkits.
Maybe only first 3 is competing.
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.
QT/embedded
The only strong widget-set competitor, besides FLTK.
seems similar to GTK. Definitely more suited to embedded environment. [an article that likes it]