Orbiter refactoring - the new design
| This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto. |
Here's a simplified partial UML:
[Orbiter_Refactoring_Orbiter_Renderers.png]
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.
PlutoGraphic class is isolated in a new h/cpp since it’s not directly related to DesignObj_Orbiter class.
These changes didn't affect Orbiter’s behavior.
Object Renderers
[Orbiter_refactor_Object_Renderer.png]
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 overriden in order to create the xml with touch zones for datagrid's cells).
