All of the source for LinuxMCE proper is under src/, and you can snag a copy of the code at
http://svn.charonmedia.org/svn/trunk/Orbiters at their core deal with DesignObjs, which may or may not contain other child designObjs. A design obj that contains everything on a screen will most likely be attached to a screen.
These relationships start at the database, so it's important that you figure out what's going on there.
We use a home grown utility to create C++ access classes from the database, called sql2cpp. It is described in the wiki here:
http://wiki.linuxmce.org/index.php/Sql2cppsql2cpp is run on the build version of the database (you should never run it on your own local copy, because certain things are stripped out from a packaged release that are only used when building the release, but they are necessary to be in the resulting sql2cpp library.) to create the libraries pluto_main, pluto_media, pluto_telecom, etc. These libraries are used ALL over the system, and especially in Orbiter, to abstract access to the database. If you look inside pluto_main/ , you will find a whole set of Define_xxxxxxx.h files. These are constants defined from the individual Define columns in each part of the database. This is used to distinctly reference a database element inside the code, and is used quite a bit. DESIGNOBJTYPE_Web_Browser_CONST for example, would be referring to the row in the database that contains the Description Web Browser. Use this to trace the relationships between the code and the database.
Orbiter/ itself, is where you'll be spending most of your time. It is a beast. well over 200,000 lines of code. The vast majority of it is screen logic, with rendering parts pushed out to sub-classes. The majority of the stuff that makes orbiter work is in Orbiter.cpp. Here you'll find the different designobj types, what they can do, as well as variable substitutions, etc. All of the different devices use the same code. The orbiter itself comes in two main flavors, a fat client, which pushes the graphics to the target device, and orbiter itself runs on the target device, sending DCE messages back, and a proxy client, which is how the Cisco 7970, Web Orbiter, and Mobile Phone orbiters work. These work by assembling things together just like the fat clients, but instead render out a flattened image, which is then pushed to the clients, which accept the image, and merely transmit back "button presses".. regardless of this, the same code is used, just a different rendering subclass.
It must be noted that since Orbiter depends heavily on the database, and we have a shared database infrastructure in place, building a theme packet format is not practical. Instead, theme developers should work in a small grouping of teams, one of them having a username to our sqlcvs repository, and submitting stuff for it as needed, as well as providing the necessary skin directory so that a package can be made. This ultimately means, that new skins become available to everyone as they update their database, and they can be selected as needed, with the system downloading the skin package as needed. Once a skin has been installed, a renegeration is needed, and the skin will be used from that point on.
Anything done in designer, has to be generated. This entails pre-rendering output versions of graphics, so that they can be used by orbiter. OrbiterGen does this. OrbiterGen takes the database definitions, and tries to figure out the largest pieces of a designobj to render into one graphic (it tries to reduce to as few rendered graphics as possible, so if you have a static screen that doesn't change, it will render all of the pieces on it as a single graphic.) This not only includes statically placed designobjs, but also designobjs of type Array (when you see a row of buttons such as the scenario buttons? those are button arrays), which are replicated and then rendered.
It's worth noting that we use PNGs and MNGs exclusively, alpha channels can be used, and are used quite a bit. Depending on the orbiter implementation, a background color may or may not be rendered (in UI1, all transparent pixels take on the background image.).
In the spirit of pre-rendering the images, any MNG graphics are ALSO pre-rendered. That is, each and every frame is output, and composited together with its underlying exposed pieces. This also means, that if you have potentially any overlapping animation, interesting artifacts may result due to OrbiterGen not able to resolve the fact that a completely independent state of frames needs to be rendered.
-Thom
