Understanding the sources

[muellerph]

Hello devs,

I'm trying to get into the sources, because maybe you will see later some code.

I tried to interpret as much as I can, but you will better know than I do how difficult this is without any hints.

May you just shortly sum up how the whole setup is, especially how the communication between vomp <-> vompserver <-> vdr is meant to be?
Which classes are the important ones?
For sure I don't need all classes described as at the end the sources will tell the rest.

As always this description should be placed into the respective README in the cvs.

Thanks in advance,

Philipp

PS: To my person:
I'm located in Ottobrunn/Munich, Germany. I worked on KSpread, so I have some experience with C++. I stopped working on KSpread because of lack of time - when my boy was born. Now 3 years later and another 2 daughters we moved into a house and have a full network installed in every room. So a VOMP setup is perfectly fitting.

Now only the functionality and visual impression must be prove to fit the expectations of my wife. So I really intend to work on enhancing VOMP.

[Chris]

Hello, I'm always glad to see more developer interest.

I appreciate it is difficult to understand other people's code, it always is. But it is also difficult to sum it all up! I'll have a little go anyway. I will be very glad to answer any specific questions you have.

So, main.cc makes instances of all the single instance classes, Log, Timers, hardware classes, ViewMan, VDR, etc. Then it starts the Command object which deals with all user input to the program. After this, the rest of the program is driven by Views being made and put on screen. The ViewMan maintains the stack of views, and when remote buttons are pressed they go through the Remote object, into Command, then into ViewMan which gives them to the top View.
Most of the classes beginning with v are derived from View and are views to be displayed on screen. Classes beginning with w are widgets. As for playing video, a VVideoLive or VVideoRec is created. The created class creates a Player object which deals with asking VDR for data, sending it to the hardware objects and it also handles all the different playback states.

As for communication.. The only class to think about in the client is VDR. All the VDR specific TCP connection code is in there. VDR uses a TCP object for actual TCP communcation. Vomp uses UDP broadcast to find the vompserver plugin but after that it uses just a single TCP connection to the vompserver plugin for all its communication. In the plugin, a MVPServer object listens for connections and hands them out to MVPClient objects. The MVPClient class handles all the TCP communication from the client. MVPClient uses other objects to represent a currently streaming recording (RecPlayer) and currently streaming live (MVPReceiver). Most of the code to integrate with VDR itself is in MVPClient, but some is in RecPlayer and MVPReceiver.

I don't know if this is on target at all, I hope so though!

Also, glad to see another wife driving vomp development

Chris