[cae898]: src / dox / mainpage.dox Maximize Restore History

Download this file

mainpage.dox    99 lines (75 with data), 3.2 kB

/*!
 \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.
   For more details see \ref introduction

 \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/
       - celeste/ Contains the code for celeste
       - deghosting/  Contains the deghosting code
       - dox/     Contains the parts for generating documentation
       - foreign/ Contains foreign libs (mostly with modification for hugin)
       - hugin1/  Contains all libs and programs which depends on wxWidgets
                  (mainly the GUI programs)
       - hugin_base/  Contains the base functionality
                  (code in this directory does not depends on wxWidgets and
                  should not link against wxWidgets)
       - hugin_cpfind/  Contains the code of the control point detector
       - hugin_qtbase/  Contains the old gui written in QT
       - lens_calibrate/ Contains the lens_calibrate lib and program
       - matchpoint/  Contains the matchpoint program
       - tools/    Contains most of the command line tools
       - translations/  Contains the translations
       
 \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.
      
*/