[an error occurred while processing this directive]
Main Page | Modules | Namespace List | Class Hierarchy | Class List | File List | Namespace Members | Class Members | File Members | Related Pages

hugin source code documentation

0.1

Introduction

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

Panorama Model

Holds the Panorama state. The command objects that inherit from PanoCommand should be used to change the panorama.

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.

Building

Hugin now builds with cmake:


   cmake .
   make
   make install

   

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

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:


      /** 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);

      }
      
      

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.


Generated on Mon Sep 20 01:01:25 2010 for Hugintrunk by doxygen 1.3.9.1