Changes

Jump to navigation Jump to search
4,026 bytes removed ,  12:50, 14 April 2009
Line 102: Line 102:     
Below is the technical abstract for Marbles:
 
Below is the technical abstract for Marbles:
===== without libglade library =====
     −
:[[Image:marbles-flowchart.png|left| Marlbes-development environment.]]
+
===== With LibGlade library =====
 
  −
 
  −
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
  −
Here visual UI representations gives an option to select widgets, authoring tool will assist the users to place the widgets on frame and also do some prechecks on UI widget compatibility.Program generator then generates the optimized code based on UI types, positions and associates event handlers to the widgets. Views should be handled independently and it includes final checks on widgets too. History generation is being done side by side to facilitate recoveries if error occurs and finally, output generation ( both UI and code output ) . Code output from the software will be stored in specific directories or in database.
  −
 
  −
Database comes into picture while history creation with simple as undo/redo or more complex project development stages. Typically database would store the fields like
  −
 
  −
#Table: Widget
  −
#*Fields: Widget id,name,label,icon, height, width, position,parent_container id ,visible,focus-type, param1,param2
  −
#*Widget table will contain widget id , it's name,label,positional parameters, id to its paraent container, and other parameters specific<br>to widget functionality like for checkbox we could have parameters like "default check". This table includes all type of widgets i.e.<br>containers, menu, buttons, checkbox etc
  −
#Events
  −
#*Fields: Eventid, type,signalid, signal-handler,object,widget-id(foreign key),params
  −
#*Events table will register the events associated with the widgets. Note that signal handler would be called as object.signal-handler() with<br> parameters if necessary. 
  −
#Navigation-Views
  −
#*Fields: Widget-id,pos-x,pos-y,col-span,row-span,padding,Expanding(boolean), shrink(boolean), colorfill(boolean), params
  −
#*This gives option to handle view effectively. Options are id, postions, span space, padding space, expanding ( yes/ no ), shrinking<br>(yes/no), color fill and other parameters. This table would be mainly responsible for generating views in desktop UI.
  −
#Navigation-main
  −
#*Fields: Widgetid,name,description,activate(boolean),children-id(foreign key),delete(boolean),params
  −
#*This table will be the database of UI application and UI graphics can be straight generated using this table. This table would be overwritten with widgetids everytime, when an object is added to on VISUAL UI. this contains field like widget id,<br>name desc, chidren-id ( widget that comes under it ) and other functional or positional parameters. delete column will help in faking delete<br>option( more on this later ).
  −
#*This table can also be shared in network and associated with other UI applications. Here XML messaging can be used with DOM/SAX parser support in this application.
  −
 
  −
'''Description'''
  −
 
  −
Initially, navigation-main row will be initiated with widget-id say 0 and delete will be false
  −
When user drags an widget on canvas, new widget will be created and a new entry comes in navigation-main table. Similarly children-widgets are created and subsequent entries will be given in specific tables. In this way, a whole tree-view of UI application would then be saved in database.
  −
For undo operation, navigation-row entry for "delete" can be set to true, similarly for redo operation, entry would be false again.
  −
 
  −
 
  −
'''How output is generated'''
  −
 
  −
program generator will read navigation-main and widgets specified by user will be initiated with given options. Navigation-view will then be fetched and widgets will then be arranged according to view-instructions.
  −
Code generated will be temporarily stored in files ( say /tmp) , can be permanent stored if user wants to save the UI-application.
  −
 
  −
'''Note'''
  −
 
  −
Special care will be given on debugging facility. since pygtk is used in UI application, sugar-bot integration would not be difficult to achieve. I will also try to include modules for sugar-bot debugging facility to facilitated direct unit-testing.
  −
 
  −
===== with libglade library =====
      
#Choosing UI widgets and dropping on canvas ( view )            |
 
#Choosing UI widgets and dropping on canvas ( view )            |
122

edits

Navigation menu