/*!
 \mainpage hugin source code documentation

 \section intro Introduction

   The code is divided in a platform and toolkit independent
   (mostly) abstraction of a panorama, PT::Panorama and a wxwindows
   GUI.


 \section model Panorama Model
   Holds the Panorama state. The command objects that
   inherit from PanoCommand should be used to change the panorama.
   
 \section GUI GUI

   The GUI is written using the wxWindows toolkit.  My idea was that
   the gui should not be a monolithic block, but split into smaller
   parts (for example the different tabs in the main frame are a idea
   how the GUI should be split in different panels that will recieve
   notifications when the model changed and will update themselves
   accordingly. These panels can also use the Commands inherited from
   PanoCommand to modify the model. The model should never be changed
   directly. By using PT::PanoCommand and a CommandHistory to execute
   them, it is very easy to implement undo/redo
   functionality. PT::Panorama will notify a PT::PanoramaObserver
   which can then notify the GUI and interested subwindows. MainFrame
   is a good candidate for PT::PanoramaObserver.

   XRC is used for the GUI design. Each custom Panel should have its
   own XRC file, so that people can work with on different parts of
   the GUI without to much trouble. The MainFrame will then use the
   unknown class to load the different custom Panel. CPEditorPanel
   is an example how this can be done. Note that there is only a
   global namespace for all xrc files. Names in the xrc files should
   therefore start with a prefix that indicates the parent panel.

 \section build Building

   Hugin now builds with cmake:

   \verbatim

   cmake .
   make
   make install

   \endverbatim

   The project's directory structure (this list is completely out-of-date):

   - hugin/
     - src/
       - include/ Contains all includes
         - hugin/
         - PT/
       - PT/      Contains the model classes
       - hugin/   Contains the wxwindows interface
       - qtgui/   old gui written with qt.
       - lib/     Parts that do not compile to a exe
                 (for example the stuff under PT) will
                 be linked to a static library and put here.
       - makefiles  global part of the makefiles
       - tests    various tests for the model classes directory.
                 They use the unit test framework from BOOST
                 (http://www.boost.org). They are not needed
                 to compile or run hugin.
       
 \section code Code writing

   A short list of my coding habits:
   
   indentation with 4 spaces, no tabs. Tabs often cause confusion,
   when different IDE's use different tab lengths.

   source code documentation with doxygen (http://www.doxygen.org)
   Doxygen is a useful tool and can also be used to create other
   documentation that just class interface descriptions (for example
   this document). It works by prefixing the function prototypes with
   a special comment. I usually put the documentation in the header
   files.

      The basic usage is very javadoc like:
      
      \verbatim

      /** One sentence class description
       *
       *  more detailed description
       *
       *  @todo pet the cat more often
       *  @bug  might scratch if annoyed
       */
      class Cat
      {
      public:
          /** hunt food
           *
           *  @param prey type of animals that we should hunt
           *  @return true if the cat is sated
           */
          bool HuntFood(Prey prey);

      }
      
      \endverbatim

      I haven't commented all my classes but I will complete the
      documentation of the more important ones.

      the todo and bug items will appear in a separate list, so its
      a useful tool to document some stuff that has to be fixed at
      some time but is not too important right now.

      I have also often used // FIXME comments, mainly inside *.cpp
      files, so a grep for FIXME should also reveal places where some
      more work should be done ;-)

      I usually use java like naming conventions, but wxwindows uses
      uppercase characters for the first char of a method name. I'll
      use capital letters for all wx widgets in the future to avoid
      confusion.
      
*/
