Line 73: |
Line 73: |
| #*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. |
| | | |
− | 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.
| |
| | | |
| ==== Technical Approach ==== | | ==== Technical Approach ==== |
Line 116: |
Line 91: |
| 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. |
| | | |
| | | |