Changes

2,824 bytes added ,  12:32, 3 April 2009
no edit summary
Line 69: Line 69:  
==== Technical Approach ====  
 
==== Technical Approach ====  
 
Below is the rough draft, it talks about the implementation in abstract way just to share the idea of implementation.
 
Below is the rough draft, it talks about the implementation in abstract way just to share the idea of implementation.
:[[Image:marbles-flowchart.png|left| Here is my Development environment.]]<br>
+
:[[Image:marbles-flowchart3.png|left| Marlbes-development environment.]]<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.
 
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 to <br>
 +
widget functionality like for checkbox we could have parameters like "default check". This table includes all type of widgets like containers, <br>
 +
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 would be overwritten with widgetids everytime, when an object is added to on VISUAL UI. this contains field like widget id,name,<br>
 +
desc, chidren-id ( widget that comes under it ) and other functional or positional parameters. delete column will help in faking delete option.<br> ( more on this later )
 +
 +
'''Description'''
 +
Initially, navigation-main row would be initiated with widget-id say 0 and delete to be false
 +
When user drags an widget on canvas, new widget would 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. For undo operation, navigation-row entry for "delete" can be set to false, 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.
 +
      −
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
   
Q10.  ''' What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.'''
 
Q10.  ''' What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.'''
  
122

edits