______ 
| ___ \
| |_/ /
| ___ \
| |_/ /
\____/ 
       
       

         
         
  #####  
 ##      
  ####   
     ##  
 #####   
         

_________
\__   __/
   ) (   
   | |   
   | |   
   | |   
___) (___
\_______/
         

         
         
 #####   
 ##  ##  
 ##  ##  
 ##  ##  
 ##  ##  
         

      ## 
  #####  
 ##  ##  
 #####   
  ##     
  #####  
 ##  ##  
 #####   

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''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 [http://linuxdevices.com/articles/AT9202043619.html review of options] - about 6..8 toolkits. Maybe only first 3 is competing. ---- '''GGI''' * http://www.ggi-project.org/ ---- '''SDL''' - Simple DirectMedia Layer * http://www.libsdl.org/index.php 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''' * http://microwindows.censoft.com/ 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''' * http://www.minigui.org/ 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. ---- '''DirectFb''' * http://directfb.org I'm not even sure that this is suitable. ---- '''OpenGL''' * http://www.khronos.org/opengles/index.html#framework Although this would provide exactly the desired functionality, memory footprint probably rules it out. ---- '''Dropped''' * [http://www.espial.com/index.php?action=products,espresso Espial UI toolkit] bad license * [http://www.tutok.sk/fastgl/ 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 [http://www.linuxdevices.com/articles/AT9024868021.html 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.''' ---- '''[http://www.trolltech.com/products/embedded/ QT/embedded]''' The only strong widget-set competitor, besides FLTK. ---- '''[http://www.fltk.org/ FLTK]''' seems similar to GTK. Definitely more suited to embedded environment. [http://www.techonline.com/community/tech_topic/linux/20704?print an article that likes it]
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.