Difference between revisions of "Orbiter refactoring - the new design"
Wierdbeard65 (Talk | contribs) m |
|||
| (14 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{versioninfo}} | |
| + | == Orbiter Renderers == | ||
| − | + | === General information === | |
| − | + | ||
| − | + | ||
All the methods from Orbiter which have rendering functionality have been moved in OrbiterRenderer. Same for functions used to display dialogs or a progress. | All the methods from Orbiter which have rendering functionality have been moved in OrbiterRenderer. Same for functions used to display dialogs or a progress. | ||
| + | |||
Orbiter creates a custom renderer when it starts, using an OrbiterRendererFactory. Based on the graphic engine used, a specific OrbiterRenderer is created. Orbiter has a method Renderer() which gives access to renderer functionality to other classes. | Orbiter creates a custom renderer when it starts, using an OrbiterRendererFactory. Based on the graphic engine used, a specific OrbiterRenderer is created. Orbiter has a method Renderer() which gives access to renderer functionality to other classes. | ||
| − | + | ||
| + | LinuxMCE Graphic class is isolated in a new h/cpp since it’s not directly related to DesignObj_Orbiter class. | ||
| + | |||
| + | |||
| + | From Orbiter there are derived classes with specific implementation: | ||
| + | |||
| + | - Orbiter_Win32 (which overrides SelfUpdate method - uses OrbiterSelfUpdate class to update orbiter's binary) | ||
| + | |||
| + | - OrbiterLinux (X11 stuff, XRecording, GrabPointer/GrabKeyboard, window manager) | ||
| + | |||
| + | - OrbiterBluetooth (creates a BDCommandProcessor and uses PhoneDetection to detect/connect to smartphones) | ||
| + | |||
| + | - Proxy_Orbiter (has a tcp server, communicates with apache, creates xml for cisco phone). | ||
| + | |||
These changes didn't affect Orbiter’s behavior. | These changes didn't affect Orbiter’s behavior. | ||
| + | Here's a simplified partial UML: | ||
| + | |||
| + | |||
| + | [[Image:Orbiter_Refactoring_Orbiter_Renderers.png]] | ||
| + | |||
| + | |||
| + | === Orbiter creation and destruction === | ||
| + | |||
| + | Here's a sequence diagram. Orbiter's framework thread should be handled by the framework. Additional threads like OpenGL's thread will be handled (created/destroyed) in OrbiterRenderer_OpenGL. | ||
| + | |||
| + | [[Image:Orbiter_Seq_diagram.png]] | ||
| + | |||
== Object Renderers == | == Object Renderers == | ||
| − | + | === General information === | |
| + | |||
Each class derived from DesignObj_Data has an ObjectRenderer associated. The classes derived from ObjectRenderer is created using ObjectRendererFactory and can differ from engine to engine or shared between engines. We can create an AnimatedDatagridRender_OpenGL which will work only with opengl, but we can create a ClassicColoredDatagridRenderer which can be used for all engines. | Each class derived from DesignObj_Data has an ObjectRenderer associated. The classes derived from ObjectRenderer is created using ObjectRendererFactory and can differ from engine to engine or shared between engines. We can create an AnimatedDatagridRender_OpenGL which will work only with opengl, but we can create a ClassicColoredDatagridRenderer which can be used for all engines. | ||
| − | The AnimatedDatagridRenderer is not implemented now, only DatagridRenderer which has the same behavior as the one we are using today. | + | |
| − | Additionally, we are using now a custom datagrid for Bluetooth_Dongle : DataGridRenderer_Bluetooth (which does extra things on overriden RenderObject method) and one for Proxy_Orbiter : DataGridRenderer_Proxy.cpp (RenderCell is | + | The AnimatedDatagridRenderer is not implemented now, only DatagridRenderer which has the same behavior as the one we are using today. Additionally, we are using now a custom datagrid for Bluetooth_Dongle : DataGridRenderer_Bluetooth (which does extra things on overriden RenderObject method) and one for Proxy_Orbiter : DataGridRenderer_Proxy.cpp (RenderCell is overridden in order to create the xml with touch zones for datagrid's cells). |
| + | |||
| + | |||
| + | [[Image:Orbiter_refactor_Object_Renderer.png]] | ||
| + | |||
| + | |||
| + | === DataGridRenderer class === | ||
| + | |||
| + | DataGridRenderer class is derived from ObjectRenderer. ObjectRenderer has an owner, a DesignObj_Orbiter, which contains to deserialized data with info about that object, type, etc. In DataGridRenderer's case, the owner is a DesignObj_DataGrid. | ||
| + | |||
| + | ObjectRendererFactory creates the DataGridRenderer instance for a DesignObj_Orbiter when object's type is DESIGNOBJTYPE_Datagrid_CONST: | ||
| + | |||
| + | |||
| + | [[Image:Orbiter_Refactor_ObjectRendererFactory.PNG]] | ||
| + | |||
| + | |||
| + | |||
| + | Here's a small UML for DataGridRenderer class: | ||
| + | |||
| + | |||
| + | [[Image:Orbiter_Refactor_DataGridRenderer.png]] | ||
| + | |||
| + | |||
| + | NOTE: The datagrid renderers are passive objects. They cannot handle users input events by themselves. Another step in refactoring process will be needed in order to accomplish this. | ||
| + | |||
| + | [[Category:Orbiters]] | ||
Latest revision as of 16:55, 5 May 2010
| Version | Status | Date Updated | Updated By |
|---|---|---|---|
| 710 | Unknown | N/A | N/A |
| 810 | Unknown | N/A | N/A |
| 1004 | Unknown | N/A | N/A |
| 1204 | Unknown | N/A | N/A |
| 1404 | Unknown | N/A | N/A |
| Usage Information | |||
Contents
Orbiter Renderers
General information
All the methods from Orbiter which have rendering functionality have been moved in OrbiterRenderer. Same for functions used to display dialogs or a progress.
Orbiter creates a custom renderer when it starts, using an OrbiterRendererFactory. Based on the graphic engine used, a specific OrbiterRenderer is created. Orbiter has a method Renderer() which gives access to renderer functionality to other classes.
LinuxMCE Graphic class is isolated in a new h/cpp since it’s not directly related to DesignObj_Orbiter class.
From Orbiter there are derived classes with specific implementation:
- Orbiter_Win32 (which overrides SelfUpdate method - uses OrbiterSelfUpdate class to update orbiter's binary)
- OrbiterLinux (X11 stuff, XRecording, GrabPointer/GrabKeyboard, window manager)
- OrbiterBluetooth (creates a BDCommandProcessor and uses PhoneDetection to detect/connect to smartphones)
- Proxy_Orbiter (has a tcp server, communicates with apache, creates xml for cisco phone).
These changes didn't affect Orbiter’s behavior.
Here's a simplified partial UML:
Orbiter creation and destruction
Here's a sequence diagram. Orbiter's framework thread should be handled by the framework. Additional threads like OpenGL's thread will be handled (created/destroyed) in OrbiterRenderer_OpenGL.
Object Renderers
General information
Each class derived from DesignObj_Data has an ObjectRenderer associated. The classes derived from ObjectRenderer is created using ObjectRendererFactory and can differ from engine to engine or shared between engines. We can create an AnimatedDatagridRender_OpenGL which will work only with opengl, but we can create a ClassicColoredDatagridRenderer which can be used for all engines.
The AnimatedDatagridRenderer is not implemented now, only DatagridRenderer which has the same behavior as the one we are using today. Additionally, we are using now a custom datagrid for Bluetooth_Dongle : DataGridRenderer_Bluetooth (which does extra things on overriden RenderObject method) and one for Proxy_Orbiter : DataGridRenderer_Proxy.cpp (RenderCell is overridden in order to create the xml with touch zones for datagrid's cells).
DataGridRenderer class
DataGridRenderer class is derived from ObjectRenderer. ObjectRenderer has an owner, a DesignObj_Orbiter, which contains to deserialized data with info about that object, type, etc. In DataGridRenderer's case, the owner is a DesignObj_DataGrid.
ObjectRendererFactory creates the DataGridRenderer instance for a DesignObj_Orbiter when object's type is DESIGNOBJTYPE_Datagrid_CONST:
Here's a small UML for DataGridRenderer class:
NOTE: The datagrid renderers are passive objects. They cannot handle users input events by themselves. Another step in refactoring process will be needed in order to accomplish this.
