122
edits
Changes
Jump to navigation
Jump to search
Line 73:
Line 73: − 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. − − − :'''Processing''' − − #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. Line 116:
Line 91: − +
no edit summary
#*The python bindings (PyGTK) of this toolkit are elegant and both GTK+ and PYGTK have excellent documentation.
#*The python bindings (PyGTK) of this toolkit are elegant and both GTK+ and PYGTK have excellent documentation.
==== Technical Approach ====
==== Technical Approach ====
Post-building activities like activity creation from python source code, sharing source code using xo bundle can be done later.
Post-building activities like activity creation from python source code, sharing source code using xo bundle can be done later.
I have also made a plan without libglade library but after getting suggestions from sugar members, I removed that in my technical approach. Whole design is thus made very simple.
I have also made a plan without libglade library using database storage in my design 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.