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-flowchart3.png|left| Marlbes-development environment.]]<br> | + | :[[Image:marbles-flowchart.png|left| Marlbes-development environment.]]<br> |
| | | |
| | | |
Line 79: |
Line 79: |
| #Table: Widget | | #Table: Widget |
| #*Fields: Widget id,name,label,icon, height, width, position,parent_container id ,visible,focus-type, param1,param2 | | #*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 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> | + | 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. | + | menu, buttons, checkbox etc<br/> |
| #Events | | #Events |
| #*Fields: Eventid, type,signalid, signal-handler,object,widget-id(foreign key),params | | #*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. | + | #*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 | | #Navigation-Views |
| #*Fields: Widget-id,pos-x,pos-y,col-span,row-span,padding,Expanding(boolean), shrink(boolean), colorfill(boolean), params | | #*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> | + | #*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. | | ( yes /no ), color fill and other parameters. This table would be mainly responsible for generating views in desktop UI. |
| | | |
| #Navigation-main | | #Navigation-main |
| #*Fields: Widgetid,name,description,activate(boolean),children-id(foreign key),delete(boolean),params | | #*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> | + | #*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 ) | + | 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''' | | '''Description''' |