Marbles: Difference between revisions

(31 intermediate revisions by the same user not shown)

Line 65:

# Exception handlers, should be interactive for users and should take minor decisions automatically.

==== Basic Design Principles ====

Marbles is the GUI builder tool for pygtk almost like glade, but would be optimized for sugar environment.Basic components include:

#'''Python''' Python is powerful,easy and fun. It is an excellent choice both for development and usages for children,students as well for professionals for even writing complex applications.if GUI builder is to be compared with RAD, I would say R(Rapid) in RAD stands for python.

#'''GTK+''' A face for GNOME, Sugar and other desktop managers.

#*The python bindings (PyGTK) of this toolkit are elegant and both GTK+ and PYGTK have excellent documentation.

==== Technical Approach ====

Below is the technical abstract for Marbles:

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

Thanks to '''James Henstridge''' and for his wonderful work on libglade which makes it easier to store the UI widget information and it's actions in xml file called GLADE. Using libglade will not only save the time of development but also makes the Marbles-output as platform independent. We can share the glade file for UI over network and recreate or edit the current glade file to make it more complex. It gives an option for children to play with it.

~~ ~~

I have also made a design without libglade library using database storage but after getting suggestions from sugar members, I removed that in my technical approach. Whole design is thus made very simple. Mentors can read that approach in my original GSOC proposal submitted to google.

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

===== With LibGlade library =====

~~#*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 functionality like for checkbox we could have parameters like "default check". This table includes all type of widgets i.e. 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 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 (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, 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 ).

~~#*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'''~~

Libglade is a library designed to dynamically load a user interface from an XML file on disk. These UI description files can be created using the Glade UI builder. It provides several options for connecting callbacks up to the interface including an `autoconnect' option that scans the program's symbol table for callback functions.

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

#Choosing UI widgets and dropping on canvas ( view ) |

#Showing the current output on canvas ( Temp glade file ) | - UI builder tool

#Getting the output in Python code |

#Option for Activity creation, Exporting to xo bundle, Debugging tool for Developers, sharing of code etc. | - Post building activities

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

Creating GTK UI that can show various widgets icons and gives an option to select with the mouse, dragging and then dropping on canvas. It will be saved in glade-format file. this temporary glade file will then be read using libglade library in python and output can be shown on canvas.

~~Code generated~~ will be ~~temporarily stored~~ in ~~files ( say /tmp) ,~~ can be ~~permanent stored if user wants to save the UI-application~~.

~~'''Note'''~~

After completion of dragging and dropping, User can build the application using build activity in Marbles which takes input a glade file and outputs a python source code ( PyGTK framework ) capable of producing same output as glade does.

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

Post-building activities like activity creation from python source code, sharing source code using xo bundle can be done later.

==== Design Goals ====

:'''Design Goals'''

#'''Good design''' I am greatly impressed by Turtle activity of sugar, and would like to achieve if not same, then try to reach the UI clearity as much as possible. Usability would be primary aim for design.

#'''Good help system''' Since it involves various new widgets which children might not know .It better to have help-activity along with GUI builder to offer help to users for building the UI.

#'''Automatic Decision System''' Minor decisions for widget placements, size ratio with desktop resolution and other script associations should be done automatically.

#'''User Input''' Mouse input is more preferrable than Keyboard input.

#'''Final Considerations''' Below are the final considerations for Marbles (Future goals as well)

#*'''Quality''' prefers quality of features over quantity.

#*'''Promote Collaboration''' Promote collaboration through good documentation, careful modular design and quality code.

#*'''Modularity''' Design will allow extending to other target languages and other GUI toolkits.

Line 117:

Line 123:

In summer, I plan to follow the following schedule:

#Preparation phase( Time : April 25 - ~~may25~~ )

#'''Preparation phase'''( Time : April 20 - may15 )

#*gathering requirements of the project

#*getting involved with Mentor in verifying and validating the requirements.

#*~~Architectural design / Pseudo code~~.

#* Writing abstract classes for all widgets and specifications

#*This phase, I would be communicating with people as much as possible, getting requirements and verifying with people or community. I would also go to the pre-releases of similar softwares to get prons and cons and trying to improve in ~~our~~ project development.I am sure to get community support on this very interesting project.

#* Creating of canvas to support widget dragging and dropping.

#Coding Phase ( Time: May 25- July1 { This phase would be subdivided to different phases } )

#*This phase, I would be communicating with people as much as possible, getting requirements and verifying with people or community. I would also go to the pre-releases of similar softwares to get prons and cons and trying to improve in my project development.I am sure to get community support on this very interesting project.

#*~~divisions for coding timeline~~

#*'''Delieverables''' Final design and technical approach to mentors and getting reviewed by them.

#* ~~decide approach for~~ programming

#'''Coding Phase''' ( Time: May 15- July1 { This phase would be subdivided to different phases } )

~~#* actual coding~~, ~~testing accordingly~~

#* Implementation of program generator to generate the required code.

#* ~~documenting code parallely~~

#* Creation of programming libraries such as History generation, View modifier, function associations for code generation.

#* ~~periodically sharing information~~ with ~~mentors~~ and ~~community members~~

#* Work on intelligent sizers HBOX or VBOX to minimize the use of old technique sizers in UI creation.

~~#* This phase will include actual coding. Since I already knew the related technologies~~ and ~~familiar to sugar development process. I can devote more time to coding and thus improving the project at each phases. I will share doubts with community if occurs~~.

#* '''Delieverables''' Basic UI design with dragging and dropping facility for widgets and UI application output as a python code.

#Testing Phase ( Time: July7- July 25 )

# '''Coding & Internal Testing Phase''' ( Time: July7- July 25 )

#* ~~full~~ testing of system with different ~~phases~~

#* Creation of final UI output for UI builder.

#* Creation of help activity for helping students in UI building.

#* Full testing of system with different widgets.

#* use coverage analysis to know the redundance code and improving it further

#* ~~fixing bugs if any~~

#* Documentation support for widgets and UI creation.

~~#* Last minute changes before final submission~~

#* '''Delieverables''' Release of Marbles-Alpha version for external testing.

~~#* finish any documentation steps if left~~.

#''' Final Evaluation''' ( July 26 - END )

#* After coding, this is the most interesting part for me. Past I have also worked on code coverage tools for python and I really like this efficency measurement whicha also helps a lot in improving run-~~time. I will go~~ for ~~different~~ testing ~~tools on program, Some tools I would like to go with~~

#* This phase is basically for porting the UI builder solution to sugar's upstream development and checking for bugs in different environment.

~~#*coverage or flegleaf tools for anlaysis~~.~~ ~~

#* '''Delieverables''' full said project to sugar community.

#*I will use boost algorithms to improve run-~~time if it comes under requirement.~~

~~#Finalizing phase / Revision ( Time: from August 1 to~~ END.)

#* ~~review of code/ algorithm~~

~~#* production of coverage reports, analysis, performance etc.~~

~~#* discussions on limitations of software~~ and ~~beneficials~~.

#* ~~preparing final deployments for various systems~~.~~ ~~

~~#* Documentation stuffs would go in this phase~~

Time line: Seems very little time to do so many things, but I will try to give the best from my side.

I have worked on variety of projects ranging from web application, mobile j2me midlets, Web server management( python project ) and desktop application. One of the interesting projects I worked on is "cross platform windows explorer" which I built in python using wxwidget, in which we handled the issues like portability, searching and UI designs. If I am not exagerating, that would not be wrong to say that I am a fast learner.

I have worked on variety of projects ranging from web application, mobile j2me midlets, Web server management( python project ) and desktop application. One of the interesting projects I worked on is "cross platform windows explorer" which I built in python using wxwidget, in which we (team work) handled the issues like portability, searching and UI designs. If I am not exagerating, that would not be wrong to say that I am a fast learner.

Believe me, I have that talent needed to build and design a complex system for customers. Below are some of the projects I worked on

Line 161:

Line 162:

* Check out the source code of shallow file browser at http://code.google.com/p/shallow-file-browser. Do check the snapshot of browser in action.

* Minute-Shell: Well, it's a part of my course project. I created a small program to emulate linux shell. This code is hosted at http://code.google.com/p/minute-shell/ .

=== Me and the community ===

@@ Line 65: / Line 65: @@
 # Exception handlers, should be interactive for users and should take minor decisions automatically.
+==== Basic Design Principles ====
+Marbles is the GUI builder tool for pygtk almost like glade, but would be optimized for sugar environment.Basic components include:
+#'''Python'''<br> Python is powerful,easy and fun. It is an excellent choice both for development and usages for children,students as well for professionals for even<br>writing complex applications.if GUI builder is to be compared with RAD, I would say R(Rapid) in RAD stands for python.
+#'''GTK+'''<br>A face for GNOME, Sugar and other desktop managers.
+#*The python bindings (PyGTK) of this toolkit are elegant and both GTK+ and PYGTK have excellent documentation.
 ==== Technical Approach ====
 Below is the technical abstract for Marbles:
 :[[Image:marbles-flowchart.png|left| Marlbes-development environment.]]
+Thanks to '''James Henstridge''' and for his wonderful work on libglade which makes it easier to store the UI widget information and it's actions in xml file called GLADE. Using libglade will not only save the time of development but also makes the Marbles-output as platform independent. We can share the glade file for UI over network and recreate or edit the current glade file to make it more complex. It gives an option for children to play with it.
-<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>
+I have also made a design without libglade library using database storage but after getting suggestions from sugar members, I removed that in my technical approach. Whole design is thus made very simple. Mentors can read that approach in my original GSOC proposal submitted to google.
-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
+===== With LibGlade library =====
-#*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'''
+Libglade is a library designed to dynamically load a user interface from an XML file on disk. These UI description files can be created using the Glade UI builder. It provides several options for connecting callbacks up to the interface including an `autoconnect' option that scans the program's symbol table for callback functions.
-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'''
+#Choosing UI widgets and dropping on canvas ( view )  		           |
+#Showing the current output on canvas ( Temp glade file )      		   | - UI builder tool
+#Getting the output in Python code                         		   |
+#Option for Activity creation, Exporting to xo bundle, Debugging tool for Developers, sharing of code etc. | - Post building activities
-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.
+Creating GTK UI that can show various widgets icons and gives an option to select with  the mouse, dragging and then dropping on canvas. It will be saved in glade-format file. this temporary glade file will then be read using libglade library in python and output can be shown on canvas.
-Code generated will be temporarily stored in files ( say /tmp) , can be permanent stored if user wants to save the UI-application.
-'''Note'''
+After completion of dragging and dropping, User can build the application using build activity in Marbles which takes input a glade file and outputs a python source code ( PyGTK framework ) capable of producing same output as glade does.
-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.
+Post-building activities like activity creation from python source code, sharing source code using xo bundle can be done later.
+==== Design Goals ====
+:'''Design Goals'''
+#'''Good design'''<br> I am greatly impressed by Turtle activity of sugar, and would like to achieve if not same, then try to reach the UI clearity<br>as much as possible. Usability would be primary aim for design.
+#'''Good help system'''<br>Since it involves various new widgets which children might not know .It better to have help-activity along with GUI<br>builder to offer help to users for building the UI.
+#'''Automatic Decision System'''<br>Minor decisions for widget placements, size ratio with desktop resolution and other script associations should be done automatically.
+#'''User Input'''<br>Mouse input is more preferrable than Keyboard input.
+#'''Final Considerations'''<br> Below are the final considerations for Marbles (Future goals as well)
+#*'''Quality'''<br>prefers quality of features over quantity.
+#*'''Promote Collaboration'''<br>Promote collaboration through good documentation, careful modular design and quality code.
+#*'''Modularity'''<br>Design will allow extending to other target languages and other GUI toolkits.
@@ Line 117: / Line 123: @@
 In summer, I plan to follow the following schedule:
-#Preparation phase( Time : April 25 - may25 )
+#'''Preparation phase'''( Time : April 20 - may15 )
 #*gathering requirements of the project
 #*getting involved with Mentor in verifying and validating the requirements.
-#*Architectural design / Pseudo code.
+#* Writing abstract classes for all widgets and specifications
-#*This phase, I would be communicating with people as much as possible, getting requirements and verifying <br> with people or community. I would also go to the pre-releases of similar softwares to get prons and cons and trying to improve in our project <br> development.I am sure to get community support on this very interesting project.
+#* Creating of canvas to support widget dragging and dropping.
-#Coding Phase ( Time: May 25- July1 { This phase would be subdivided to different phases } )
+#*This phase, I would be communicating with people as much as possible, getting requirements and verifying <br> with people or community. I would also go to the pre-releases of similar softwares to get prons and cons and trying to improve in my project <br> development.I am sure to get community support on this very interesting project.
-#*divisions for coding timeline
+#*'''Delieverables''' Final design and technical approach to mentors and getting reviewed by them.
-#* decide approach for programming
+#'''Coding Phase''' ( Time: May 15- July1 { This phase would be subdivided to different phases } )
-#* actual coding, testing accordingly
+#* Implementation of program generator to generate the required code.
-#* documenting code parallely
+#* Creation of programming libraries such as History generation, View modifier, function associations for code generation.
-#* periodically sharing information with mentors and community members
+#* Work on intelligent sizers HBOX or VBOX to minimize the use of old technique sizers in UI creation.
-#* This phase will include actual coding. Since I already knew the related technologies and familiar to sugar development process. I can devote<br> more time to coding and thus improving the project at each phases. I will share doubts with community if occurs.
+#* '''Delieverables''' Basic UI design with dragging and dropping facility for widgets and UI application output as a python code.
-#Testing Phase ( Time: July7- July 25 )
+# '''Coding & Internal Testing Phase''' ( Time: July7- July 25 )
-#* full testing of system with different phases
+#* Creation of final UI output for UI builder.
+#* Creation of help activity for helping students in UI building.
+#* Full testing of system with different widgets.
 #* use coverage analysis to know the redundance code and improving it further
-#* fixing bugs if any
+#* Documentation support for widgets and UI creation.
-#* Last minute changes before final submission
+#* '''Delieverables''' Release of Marbles-Alpha version for external testing.
-#* finish any documentation steps if left.
+#''' Final Evaluation''' ( July 26 - END )
-#* After coding, this is the most interesting part for me. Past I have also worked on code coverage tools for python and I really like this <br> efficency measurement whicha also helps a lot in improving run-time. I will go for different testing tools on program, Some tools I would like<br> to go with
+#* This phase is basically for porting the UI builder solution to sugar's upstream development and checking for bugs in different environment.
-#*coverage or flegleaf tools for anlaysis.<br>
+#* '''Delieverables''' full said project to sugar community.
-#*I will use boost algorithms to improve run-time if it comes under requirement.
-#Finalizing phase / Revision ( Time: from August 1 to END.)
-#* review of code/ algorithm
-#* production of coverage reports, analysis, performance etc.
-#* discussions on limitations of software and beneficials.
-#* preparing final deployments for various systems.<br>
-#* Documentation stuffs would go in this phase
 Time line: Seems very little time to do so many things, but I will try to give the best from my side.
-I have worked on variety of projects ranging from web application, mobile j2me midlets, Web server management( python project ) and desktop application. One of the interesting projects I worked on is "cross platform windows explorer" which I built in python using wxwidget, in which we handled the issues like portability, searching and UI designs. If I am not exagerating, that would not be wrong to say that I am a fast learner.
+I have worked on variety of projects ranging from web application, mobile j2me midlets, Web server management( python project ) and desktop application. One of the interesting projects I worked on is "cross platform windows explorer" which I built in python using wxwidget, in which we (team work) handled the issues like portability, searching and UI designs. If I am not exagerating, that would not be wrong to say that I am a fast learner.
 Believe me, I have that talent needed to build and design a complex system for customers. Below are some of the projects I worked on
@@ Line 161: / Line 162: @@
 * Check out the source code of shallow file browser at http://code.google.com/p/shallow-file-browser. Do check the snapshot of browser in action.
 * Minute-Shell: Well, it's a part of my course project. I created a small program to emulate linux shell. This code is hosted at http://code.google.com/p/minute-shell/ .
 === Me and the community ===