Marbles: Difference between revisions

Line 69:

==== Technical Approach ====

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.]]

:[[Image:marbles-flowchart.png|left| Marlbes-development environment.]]

Line 79:

#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

#*Widget table will contain widget id , it's name,label,positional parameters, id to its paraent container, and other parameters specific to

widget functionality like for checkbox we could have parameters like "default check". This table includes all type of widgets like containers,

widget functionality like for checkbox we could have parameters like "default check". This table includes all type of widgets like containers,

menu, buttons, checkbox etc.

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 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 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

#*This gives option to handle view effectively. Options are id, postions, span space, padding space, expanding ( yes/ no ), shrinking

( 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,

#*This table would be overwritten with widgetids everytime, when an object is added to on VISUAL UI. this contains field like widget id,name,

desc, chidren-id ( widget that comes under it ) and other functional or positional parameters. delete column will help in faking delete option. ( 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 ( more on this later )

'''Description'''

@@ Line 69: / Line 69: @@
 ==== Technical Approach ====
 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
 #*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
 #*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
 #*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.
 #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>
+#*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'''