_   _ 
 | \ | |
 |  \| |
 | . ` |
 | |\  |
 |_| \_|
        
        

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

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

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

 _______ 
(  ___  )
| (   ) |
| |   | |
| |   | |
| | /\| |
| (_\ \ |
(____\/_)
         

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 We want to develop tuning software, not widget-set (or windowing system). So we have to '''find a lightweight API and implementation''' that abstracts the graphical and user-input HW. We have to write the tuningsoftware against this API. '''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 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. 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.fltk.org/ FLTK]''' seems similar to GTK, maybe smaller, but not as widespread.
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.