Overview
--------

- General/utility files/classes:

misc.h
vec.h
mat.h
poi.h
lssolve.h
slicedtask.h

- The game of Hex
  
hexmark.h
hexfield.h
hexboard.h
hexmove.h
hexgamestate.h
hexgame.h
hexmatch.h
hexplayer.h

- AI

carrier.h
group.h
subgame.h
connector.h
conductance.h
sixplayer.h

- GUI
asyncplayer.h
khexwidget.h
ksix.h

Explanation of statuses and semi-threading
------------------------------------------

While the computer is thinking the GUI should still function properly.
To achieve this goal one can use threading, split the background task
(in this case thinking) into small chunks or keep processing events
by directly calling kapp->processEvents() every once in a while.

Threading - which seems to be the cleanest solution - introduces more
dependencies either on phtreads or qt-mt. To keep portability problems
away phtreads were not used. QT-MT was not used because as of KDE2.2
some distributions do not include these libraries by default and almost
none of the KDE programs use it.

Splitting the background task into small chunks (and keeping the state
between two chunks!) is very hard to do in this particular case.

So, with the two other choices out that leaves us with calling
kapp->processEvents() periodically from the background task. While
it may seem a simple solution it does introduce problems when a
new HexMatch is to be created and the from current one
kapp->processEvents() was called. If HexMatch is just deleted we are
likely to end up with a SIGSEGV when control from processEvents() returns
to the deleted HexMatch. Similar problems exists when the player that is
thinking (and calling processEvents()) is changed/deleted.

Working around these problems complicates class KSix quite a bit.
