Some generic code should be moved out of gui layer. E.g. merging of break.
advancing restbreaks etc. The control layer is not supposed to have any
knowledge of what kind of timers exist. It just maintain a numer of identical
timers... So, there should be some generic rules....

BreakControl.{cc,hh} and a large part of GUI.{cc.hh} are gtkmm independent.
Generics parts should be moved to workrave/src/ or workrave/gui.

Control.cc: This class should not have any knowledge about specific timers
(breaks). It only knows about a collection of identical Timers. In the (very
far) future, this class may implement a generic/configurable mapping from timer
events to actions (GUI actions, sound, auto-away to ICQ client etc). This also
requires some configurable "break-gluing" (i.e. RB overrides MP, don't show MP
when RB is imminent). Control.cc should also take care of distributed operation.
(Short summary: no changes on short term)

GUI.cc: This class knows about specific timers/breaks (MP, RB, daily, weekly).
It starts, stops, configures and glues these breaks (see above). It uses the
BreakControl class. GUI.cc is also responsible for generating sounds. This class
might become superfluous when Control.cc implements the generic timer event to
action mapping. GUI.cc will have to be split in 2 classes:
workrave/gui/gtkmm/GUI.cc (inter-thread communication stuff, creation of gtkmm
GUI windows, Gtk::Main::run(), etc) and workrave/src/GUI.cc (toolkit independent
part). Note that workrave/gui/* and workrave/src may ONLY use each others
interface classes.

BreakControl.cc: Only talks to some well-defined interfaces
(BreakWindowInterface, ControlInterface, TimerInterface). GUI toolkit
independent. Probably move to workrave/gui. Requires some minor changes.

Advantages:
- Generation of sound not part of gui/gtkmm
- KDE/Qt port (Ronald: hint hint) can re-use a lot of code.

GUIs that want to do thing differently can bypass src/GUI.cc and BreakControl.cc

Splitting GUI.cc is not as easy as it seems.... Some GUI independent processing
should be done on the GUI thread (access to the Configurator). Perhaps this is
also a good time to merge some threads....

Done. sort of. all files are still in gui/gtkmm. but platform independent stuff
could easily be moved to a higher-level directory. 

BreakControl and GUIControl are Gtkmm independent. Toolkit dependent classes
must implement some interfaces.