122
edits
Changes
Jump to navigation
Jump to search
Line 67:
Line 67: − + − + − + − + − − − Whole design can be divided into three parts − Input --------- Processing ----------- Output − Where input is a UI canvas which shows widgets with its correct alignment. Processing is the program generator which takes the information of widgets from the canvas and output is a code generated from program generated ( Python, C/C++ or XRC source )+ − :'''Input'''+ − # It contains "Visual UI representations", UI builder tool showing the widgets − # Visual Authoring tool: It contains a canvas on which widgets can be placed. It also contains a tree structure in it's side view to view a tree strucuture to view UI application. − − + − − #Program Generator: Main spinal cord for the whole system. It takes the input as widget information from canvas and builds a UI code according to it. − #History generation: It's a module capabable of storing history of widget-activity on canvas. It links with database or files for storing history − #View Modifier: It's a seperate module and will be designed to remove the old technique of HBOXSIZER or VBOXSIZER. It will take decisions like widget placements, size, display ratio etc. − #Function Library: It associates the scripts or accelarator tags with widgets to give life to widgets. It would be responsible for "action" in UI application. − Output of processing will be a python code ( for now, but can be modified to other programming languages too ).+ − :'''Output'''+ − #Python Source Code for UI application − #UI application will be launched as a seperated pid to view the UI design. − #Automatic Activity generation from python source code, if user wants − #Automatic sharing of activity as xo bundle. − − :'''Foundations''' − − #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 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 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. − − :'''And a final set of considerations''' − − Here are the final considerations for Marbles. − #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. − − ==== Technical Approach ==== − − Here is the basic design foundations − http://socghop.appspot.com/document/show/user/chasedspeed/design − − − Below is the technical abstract for Marbles: − :[[Image:marbles-flowchart.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><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. − + − 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.+ + + + + + + + Line 172:
Line 123: − + − + − + − + − + − + − #* actual coding, testing accordingly+ − + − + − #* 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.+ − + − + + + − + − #* Last minute changes before final submission+ − #* finish any documentation steps if left.+ − + − #*coverage or flegleaf tools for anlaysis.<br>+ − − #Finalizing phase / Revision ( Time: from August 1 to END.) − − #* production of coverage reports, analysis, performance etc. − #* discussions on limitations of software and beneficials. − − #* Documentation stuffs would go in this phase − +
→With LibGlade library
==== Basic Design Principles ====
==== Basic Design Principles ====
Marbles is the pygtk GUI builder tool for pygtk almost like glade, but would be optimized for sugar environment.
Marbles is the GUI builder tool for pygtk almost like glade, but would be optimized for sugar environment.Basic components include:
#:'''Python'''
#'''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.
Python is powerful,easy and fun. It is an excellent choice both for development and usages for children,
#'''GTK+'''<br>A face for GNOME, Sugar and other desktop managers.
#:'''GTK+'''
#*The python bindings (PyGTK) of this toolkit are elegant and both GTK+ and PYGTK have excellent documentation.
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:
:'''Processing'''
:[[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.
===== With LibGlade library =====
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.
#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
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.
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.
Post-building activities like activity creation from python source code, sharing source code using xo bundle can be done later.
==== Design Goals ====
'''Note'''
:'''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.
In summer, I plan to follow the following schedule:
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
#*gathering requirements of the project
#*getting involved with Mentor in verifying and validating the requirements.
#*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 } )
#* 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.
#* '''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
#* use coverage analysis to know the redundance code and improving it further
#* fixing bugs if any
#* Documentation support for widgets and UI creation.
#* '''Delieverables''' Release of Marbles-Alpha version for external testing.
#''' 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.
#* '''Delieverables''' full said project to sugar community.
#*I will use boost algorithms to improve run-time if it comes under requirement.
#* review of code/ algorithm
#* preparing final deployments for various systems.<br>
Time line: Seems very little time to do so many things, but I will try to give the best from my side.
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
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