__     __
 \ \   / /
  \ \_/ / 
   \   /  
    | |   
    |_|   
          
          

   ___  
  / _ \ 
 | | | |
 | |_| |
  \___/ 
        

______ 
|  ___|
| |_   
|  _|  
| |    
\_|    
       
       

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

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

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 info. Strategy of OtherTuningSoftware''' The fact is that '''we don't have a good tuningsoftware at the moment'''. MegaTune and MegaTunix are closest, but they only support the features that are implemented in mot. megasquirt. '''We need''' at least 2 tuningsoftware * a '''C based''' - the most HW-resource efficient. Development is expensive. * a '''JAVA based''' (some devices support JAVA only). Worse on HW resources than C, but development is cheaper. ---- '''How do we get to the C tuningsoftware?''' * '''from MegaTunix''' or * '''write from scratch'''. 2 alternatives: ** directly to C. If we didn't need the JAVA software and had available rocket-scientist C coder resources, this would be the best way to go. or ** first JAVA, and than the C. This is more cost efficient (or better result) when we want the JAVA software anyway. Some argue that - depending on final complexity - it might be a good idea even if we didn't need the JAVA software itself. Porting to C means to add code manually for the reference counting, malloc/free/garbage collection and dynamic dispatch that the JAVA virtual machine normally does for us. If even a CLDC JAVA virtual machine is out of question, it would be best to do this with a JAVA=>native code compiler instead of manually (see [http://www.thefreecountry.com/compilers/java.shtml list). Maybe gcj that uses the egcs backend we ue anyway. The only big improvement is with the String class (bloated from Character objects in traditional JAVA) that worths to be optimized (should be possible automatically). If we can create OtherTuningSoftware/NintendoGameBoy, we should be able to easily use it (above GTK/GDK with minor porting) on notebook. If we have 2 independent C codebases for GBA and notebook in the long run, we might be doing something wrong. But 2 independent C codebases might be the only way in the short run: * fix MegaTunix ASAP '''and''' * make a GBA software. The question is if it's better to write GBA software from ground-up, or significant portion of MegaTunix can be reused. ---- '''Is it better to make GBA software from ''' * by hammering MegaTunix - there are serious doubts * or rewrite (take ideas and code from MegaTunix but mostly rewrite) The question boils down to the issue: '''How severily does it depend on gtk/glib''' ? In other words, how good is the separation between business logic and GUI ? It seems that it's a bit monolithic, but I might be wrong. Using basic classes like gpointer, ghash, etc... can be OK. But depending on gwidget for storage of essential data can be a problem. If it depends heavily on GTK/GDK/Glib, than rewrite seems to be a better option, because OtherTuningSoftware/WidgetSet suggests GTK is a no-go. ---- '''Code to share with the GBA and desktop tuning software''' - should go to OtherTuningSoftware/CommonInfrastructure ? * VEMS hardware description/configuration library (datamaps) * maybe some helper functions (for ... details...) (all wrapped up in a library). * the user-interface must be very similar. Note that OtherTuningSoftware/GoodAndBadTuningSoftware does not say "if it's a notebook, than ... , else ...". A notebook is also used in the car and it must be usable via keyboard only ** GUI layout (window-selector-pans, and widget-packing) is a small part of the tuningsoftware, and it must be configurable according to today's measures. So for small display, or big display - the layout configuration is different, but the basics are the same. Why would it be good to not reuse the implementation for the same task on another platform? ** Keyboard input is a small part of the tuningsoftware, and it must be configurable (=> same code can be used for 8 .. 101 key keyboards) according to today's measures. Keyboard input can be categorized to 2 purpose: *** navigating (catched by the framework, eg. for window selection) *** and input (passed to widgets). ---- '''See also''' * don't miss this: google keywords: design GUI control embedded lightweight
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.