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. − ===== without libglade library ===== + − <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. − '''Note''' − 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. − − ===== with libglade library ===== Line 149:
Line 96: + − 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's output will be saved in temporary glade file. this temporary glade file will then be read using libglade library in python and output will then be shown on canvas. + − −
→With LibGlade library
#*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 ====
Below is the technical abstract for Marbles:
Below is the technical abstract for Marbles:
:[[Image:marbles-flowchart.png|left| Marlbes-development environment.]]
:[[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 ) |
#Choosing UI widgets and dropping on canvas ( view ) |
#Option for Activity creation, Exporting to xo bundle, Debugging tool for Developers, sharing of code etc. | - Post building activities
#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.
After completion of dragging and dropping, User can build the application using build activity in Marbles which takes input as 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.
Post-building activities like activity creation from python source code, sharing source code using xo bundle can be done later.