Cross-Platform Client

Blueprint
Create an extensible, cross platform (Linux/Windows/Mac) client application. Application should be a solid basis on which to build future client developments.

libavg
While researching possible languages, I came across libavg. libavg is a presentation system written in C++ with a python interface designed for use in interactive kiosks, museum displays etc. It provides alot of the functionality that the existing .net client already delivers, plus some extras such as support for live video streams, alpha channel blending, animation, layering and greater support for video and image formats.

After long discussions, Dan and I decided that libavg was a worthwhile avenue to explore, and so a python client is in development which will rely on libavg to render its output. libavg is packaged by the libavg team for Linux and MacOSX, and there is an unofficial build for Windows.

Limitations
Libavg gives us alot, but it also has some limitations which we have yet to solve:
 * Webpage rendering
 * Powerpoint / OpenOffice support
 * Flash Support

Libavg have support for webpages on their list of future developments, so hopefully as the python client develops, that feature will become available to us. The other two items are unclear at this stage, although Flash support may be derived from the webpage support.

Architecture
The python client is heavily threaded, to try and avoid problems we have encountered with the .net client and regions pausing or flickering as background activities take place.

We have a very basic class diagram which should give some idea how things will be implemented.

Implementation
libavg doesn't like being called from multiple threads. To work around this, the client implements a queue which is polled by libavg for new actions to perform. The client then adds instructions to the queue for libavg to render. This gives a really nice separation between rendering logic and scheduling/downloading etc.

The current version in bazaar will render images and videos and is almost at the point where it will parse an XLF file and render it.

Transitions
We plan to support transitions with the new client between media items and between layouts as follows:


 * Each media node in the XLF file will have a transIn and transOut options child node. This will describe the transition that should be applied to the media when it is drawn and removed from the screen.
 * Each region node will have a transOut attribute. This will describe the transition that should be applied to whatever is visible in the region at the point at which the region is destroyed.
 * Each layout node in the schedule will have a transIn and transOut attribute. This will describe the transition that should be applied to the whole layout as it is drawn to the screen.

    1.jpg fadeIn fadeOut 2000 1000 fly 2500 <transOutDirection>NW</transOutDirection> <region id="47ff29524ce1f" width="1800" height="255" top="0" left="0"> <media id="130" type="image" duration="60" lkid="1" schemaVersion="1"> 130.png None</transIn> None</transOut> fadeOut</transOut> 500</transOutDuration>

Layout End of Life
For my own sanity, here's a state diagram of how layouts are disposed currently (badly!), and how I think they need to be reworked.

Screensaver
Status: Under Consideration

This has come up in conversation more than once. Python files can be used by Win32 as a screensaver. Code here. Linux / MacOSX I'm sure are viable, but I have no idea how yet.