Miniature/Development/Architecture

GUI

 * Board
 * Chat
 * Player Cards
 * Online Play

Logic

 * Game - the logic for a particular game, right now that would be just chess, but other board games could be possible too. (Chess based or other)
 * The current game controller can update the board, using FEN strings (we might want to wrap the QStrings in a simple Position container, if we add parsing API to it) and knows about the UI.
 * Pre-Game - How to find players, select a server or engine

Domain

 * Board - Represents the data structure of the board (duh)
 * Can draw a position based on a valid FEN string, say "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" encodes the start position.
 * How it works: Each figure is a QGraphicsSvgItem. This is useful since it allows fingertouchability. The board draws its position, meaning it removes all its figures children (by deletion) and then re-reads the SVG files into new QGraphicsSvgItem. Needless to say, this is inefficient. A better way would be to let the board load all figures during its construction time, put them in a vector (using enums for the indices lookup, maybe) and instead of clearing the board by deletion, just unparent the figures from the board, then reparent them into the correct position. Or just move them around, and hide those that were removed by game moves. Both should be easy and bring a good speed-up (SVG loading is quite expensive I hear). It is bascially about killing unneeded new/delete sequences.
 * Player - information about the other player, like online status, skill level
 * Player "cards" would be part of this. Currently, they only exist as some HTML-formatted text in the scene view.

Communication

 * ICS
 * Bluetooth
 * Telepathy
 * Computer Chess Engine - an offline engine should be accessed the same way any online game is, the engine does not have to be in the same task