Developers Guide - Revision history

Mcefan: /* 1. Architecture */

2012-10-25T16:05:20Z

1. Architecture

←Older revision		Revision as of 16:05, 25 October 2012
Line 12:		Line 12:
	==1. Architecture==		==1. Architecture==

	{{#lsth:Programmer's Guide\|LinuxMCE software architecture}}		{{#lsth:Programmer's Guide\| LinuxMCE software architecture }}

	<!--		<!--

Mcefan: /* 1. Architecture */

2012-10-25T16:03:18Z

1. Architecture

←Older revision		Revision as of 16:03, 25 October 2012
Line 12:		Line 12:
	==1. Architecture==		==1. Architecture==

	LinuxMCE ~~uses a modular~~ architecture. The heart of LinuxMCE, the 'main application' DCERouter is nothing but a general-purpose message router. It has absolutely no code relating to any of LinuxMCE’s functionality--it just relays messages between "Devices". The functionality of LinuxMCE is entirely in separate programs (aka "Devices") which all run independently and communicate with each other by passing messages through DCERouter over sockets.		{{#lsth:Programmer's Guide\|LinuxMCE software architecture}}

	~~[[Image:LMCE_Architecture_mini.jpg\|LinuxMCE architecture – the devices]]~~		<!--


	~~The plug~~-~~in’s are also devices, but instead of running as separate binaries, they run as dynamic libraries in DCERouter’s memory space.~~
	A LinuxMCE system can have one or more Media Directors (MD’s). Also, a Core machine can have also the functionality of a Media Director. We call it a Hybrid:		A LinuxMCE system can have one or more Media Directors (MD’s). Also, a Core machine can have also the functionality of a Media Director. We call it a Hybrid:

	[[Image:LMCE_Architecture_-_the_machines.jpg\|400px\|Linux MCE architecture – the machines]]		[[Image:LMCE_Architecture_-_the_machines.jpg\|400px\|Linux MCE architecture – the machines]]
			-->
	{{p}}		{{p}}

Mcefan: /* 1. Architecture */

2012-10-25T06:08:21Z

1. Architecture

←Older revision		Revision as of 06:08, 25 October 2012
Line 14:		Line 14:
	LinuxMCE uses a modular architecture. The heart of LinuxMCE, the 'main application' DCERouter is nothing but a general-purpose message router. It has absolutely no code relating to any of LinuxMCE’s functionality--it just relays messages between "Devices". The functionality of LinuxMCE is entirely in separate programs (aka "Devices") which all run independently and communicate with each other by passing messages through DCERouter over sockets.		LinuxMCE uses a modular architecture. The heart of LinuxMCE, the 'main application' DCERouter is nothing but a general-purpose message router. It has absolutely no code relating to any of LinuxMCE’s functionality--it just relays messages between "Devices". The functionality of LinuxMCE is entirely in separate programs (aka "Devices") which all run independently and communicate with each other by passing messages through DCERouter over sockets.

	[[Image:LMCE_Architecture_mini.jpg~~\|frame\|none~~\|LinuxMCE architecture – the devices]]		[[Image:LMCE_Architecture_mini.jpg\|LinuxMCE architecture – the devices]]


Line 20:		Line 20:
	A LinuxMCE system can have one or more Media Directors (MD’s). Also, a Core machine can have also the functionality of a Media Director. We call it a Hybrid:		A LinuxMCE system can have one or more Media Directors (MD’s). Also, a Core machine can have also the functionality of a Media Director. We call it a Hybrid:

	[[Image:LMCE_Architecture_-_the_machines.jpg\|~~frame\|none~~\|Linux MCE architecture – the machines]]		[[Image:LMCE_Architecture_-_the_machines.jpg\|400px\|Linux MCE architecture – the machines]]

			{{p}}

	==2. DCE==		==2. DCE==

Mcefan: /* 9.2.8. Mouse handlers */

2012-10-25T06:06:56Z

9.2.8. Mouse handlers

←Older revision		Revision as of 06:06, 25 October 2012
Line 602:		Line 602:
	See below the class diagram:		See below the class diagram:

	[[Image:mousehandlers.jpg\|~~frame\|none~~\|Mouse handlers – class diagram]]		[[Image:mousehandlers.jpg\|550px\|Mouse handlers – class diagram]]


Line 609:		Line 609:
	MouseIterator and MouseGovernor limit the mouse movements the only one move per x ms to prevent extreme numbers of messages burdening the system.		MouseIterator and MouseGovernor limit the mouse movements the only one move per x ms to prevent extreme numbers of messages burdening the system.
	MouseBehaviour handles special mouse behavior, such as locking axis’s, ramping and acceleration.		MouseBehaviour handles special mouse behavior, such as locking axis’s, ramping and acceleration.


	====9.2.9. HID interface====		====9.2.9. HID interface====

Mcefan: /* 9.2.7. Orbiter logic module */

2012-10-25T06:06:29Z

9.2.7. Orbiter logic module

←Older revision		Revision as of 06:06, 25 October 2012
Line 591:		Line 591:
	Just like any other device, Orbiter is derived from a {Device_name}_Command class, the wrapper class generated by DCEGen to allow the device communicate with the router. However, Orbiter is also derived from OrbiterData and IRReceiverBase.		Just like any other device, Orbiter is derived from a {Device_name}_Command class, the wrapper class generated by DCEGen to allow the device communicate with the router. However, Orbiter is also derived from OrbiterData and IRReceiverBase.

	[[Image:orbiterlogicclassdiagram.jpg\|~~frame\|none~~\|Orbiter logic – class diagram]]		[[Image:orbiterlogicclassdiagram.jpg\|550px\|Orbiter logic – class diagram]]

Mcefan: /* 9.2.1. The renderers */

2012-10-25T06:06:04Z

9.2.1. The renderers

←Older revision		Revision as of 06:06, 25 October 2012
Line 549:		Line 549:
	Here is the class diagram for derived OrbiterRenderer‘s:		Here is the class diagram for derived OrbiterRenderer‘s:

	[[Image:orbiterrenderer.jpg\|~~frame\|none~~\|OrbiterRenderer class diagram]]		[[Image:orbiterrenderer.jpg\|550px\|OrbiterRenderer class diagram]]


Line 556:		Line 556:
	Here is the class diagram for OpenGL implementation:		Here is the class diagram for OpenGL implementation:

	[[Image:openGLimplementation.jpg\|~~frame\|none~~\|OpenGL implementation]]		[[Image:openGLimplementation.jpg\|550px\|OpenGL implementation]]

Mcefan: /* 9.2 Architecture */

2012-10-25T06:05:22Z

9.2 Architecture

←Older revision		Revision as of 06:05, 25 October 2012
Line 507:		Line 507:
	===9.2 Architecture===		===9.2 Architecture===

	[[Image:architecture.jpg\|~~frame\|none~~\|Orbiter application architecture]]		[[Image:architecture.jpg\|550px\|Orbiter application architecture]]

	The present diagram shows how the Orbiter application architecture looks like. Depending on the Graphic Engine and the platform, the only modules dependent on them are “Renderers – engine specific” and “Orbiter - platform specific”.		The present diagram shows how the Orbiter application architecture looks like. Depending on the Graphic Engine and the platform, the only modules dependent on them are “Renderers – engine specific” and “Orbiter - platform specific”.

Mcefan: /* 3. DCERouter */

2012-10-25T06:02:57Z

3. DCERouter

←Older revision		Revision as of 06:02, 25 October 2012
Line 47:		Line 47:

	See below a simplified class diagram for DCERouter:		See below a simplified class diagram for DCERouter:
	[[Image:DCERouter.jpg\|~~frame\|none~~\|Simplified class diagram for the DCE router]]		[[Image:DCERouter.jpg\|550px\|Simplified class diagram for the DCE router]]



	==4. The binary communication protocol==		==4. The binary communication protocol==

Tschak909: /* 2. DCE */ Add a new section.

2011-05-09T11:06:41Z

2. DCE: Add a new section.

←Older revision		Revision as of 11:06, 9 May 2011
Line 36:		Line 36:
	Another important library is PlutoUtils. It has cross-platform wrapper classes to handle file, strings, processes, threads synchronization, database utils, etc.		Another important library is PlutoUtils. It has cross-platform wrapper classes to handle file, strings, processes, threads synchronization, database utils, etc.

			===Developing a DCE Device===
			'''A new tutorial for [[Developing a DCE Device]] is available. This focuses on developing a device using C++ and the DCE and PlutoUtils libraries.. A new GSD tutorial for Ruby is forthcoming.'''

	==3. DCERouter==		==3. DCERouter==

Icosahedron: Fixed a couple incorrect paragraph numbers

2011-04-20T02:11:26Z

Fixed a couple incorrect paragraph numbers

←Older revision		Revision as of 02:11, 20 April 2011
Line 597:		Line 597:
	OrbiterData helps Orbiter deserialize the data needed for its graphic objects, data serialized by OrbiterGen. IRReceiverBase is the base class for all IR receiver devices and it translates IR codes into actions, base on the current screen type and remote layout.		OrbiterData helps Orbiter deserialize the data needed for its graphic objects, data serialized by OrbiterGen. IRReceiverBase is the base class for all IR receiver devices and it translates IR codes into actions, base on the current screen type and remote layout.

	====9.2.7. Mouse handlers====		====9.2.8. Mouse handlers====

	The goal of handlers is the interpret mouse movements and perform specific actions depending on current screen type. This is one of the main features add in UI2 version.		The goal of handlers is the interpret mouse movements and perform specific actions depending on current screen type. This is one of the main features add in UI2 version.
Line 612:		Line 612:


	====9.2.7. HID interface====		====9.2.9. HID interface====

	This module gets events from the Fiire remote. See below the class diagram:		This module gets events from the Fiire remote. See below the class diagram:
Line 621:		Line 621:


	====9.2.8. Generic HID Interface====		====9.2.10. Generic HID Interface====

	The Generic HID Handler is implemented in http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-0810/src/Orbiter/Linux/GenericHIDInterface.cpp and http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-0810/src/Orbiter/Linux/GenericHIDInterface.h		The Generic HID Handler is implemented in http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-0810/src/Orbiter/Linux/GenericHIDInterface.cpp and http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-0810/src/Orbiter/Linux/GenericHIDInterface.h