Work on Issue #44: Removed GLContext interface and merged functionality into GlCanvas. Introducing abstract (Qt-free) tgt::GlContextManager interface, being implemented by tgt::QtContextManager. Further clean up of related code.

CampvisApplication manages multiple DataContainers, updated PipelineTreeWidget to show correct DataContainer/Pipeline/Processor hierarchy

fixed VolumeExplorer::updateProperties()

Removing TBB library from /ext making it fully external (user has to install TBB himself). Adapted CMake files. Adapted include directions

Refactored DataNameProperty: Got rid of issueWrite() and connect(). Automatic invalidation of connected (shared) DataNameProperties is now delegated to AutoEvaluationPipeline.
ATTENTION: needs TBB 4.2 (not yet in repository, will be changed later)

Refactoring pipeline concept #7: Implemented automatic parsing of include files for pipeline registration

Refactoring pipeline concept #6: Introducing automatic creating of pipeline registration file using CMake

Refactoring pipeline concept #5: Moved Pipeline registration to modules module and gen_pipelineregistration.h which will soon be generated by CMake.

Refactoring pipeline concept #4: (Almost) got rid of hard pipeline definition in campvis.cpp. Implemented console argument parsing in CampvisApplication dynamically adding the pipelines listed as arguments

Refactoring pipeline concept #2: Got rid of distinguishing between AbstractPipeline and VisualizationPipeline. Every AbstractPipeline is also a VisualizationPipeline. However, AbstractPipeline does not care about evaluating its components - this has to be implemented in its subclasses.
AutoEvaluationPipeline subclasses AbstractPipeline and automatically evaluates the pipeline by listening to the signals of its components and calling the corresponding process() methods.

introducing AbstractProcessor::updateProperties(DataContainer&) which is automatically called by AbstractPipeline when a processor invalidates its INVALID_PROPERTIES flag

Further work on Issue #141: Introducing TrackballNavigationEventListener::reinitializeCamera() with tgt::Bounds or the new IHasWorldBounds interface as argument

work in Issue #141: Implemented listening to viewport size property in TrackballNavigationEventListener and thus removed obsolete TrackballNavigationEventListener::SetViewportSize().

Instead of having the LQ mode tied to the pipeline, each VisualizationProcessor has now a lqMode property effectively halfsampling the viewport size. The TrackballNavigationEventHandler was adapted to these changes and thus simplified.

Even though many float-based properties derived from
FloatingPointProperty used the same step value, T(0.01), it had to be
specified when instantiating them. To reduce boilerplate code in
property constructors, FloatingPointProperty now uses T(0.01) as the
default step value.

Even though all integer-based properties derived from NumericProperty
used the same step value, T(1), it had to be specified when
instantiating them. To reduce boilerplate code in property
constructors, NumericProperty now uses T(1) as the default step value.

Numeric properties were previously incremented and decremented by 1 cast
to the property's underlying type, e.g. tgt::vec2(1). That worked fine
for integer-based properties, but those storing floating-point numbers
could benefit from using the step value in decrement() and increment().
Now that's exactly how NumericProperty behaves.

work on #135: changed VisualizationProcessor::_renderTargetSize to pointer and introducing VisualizationProcessor::setViewportSizeProperty()

Revised event handling system: Got rid of campvis::AbstractEventHandler and replaced with functionality of tgt::EventListener and tgt::EventHandler

FloatPropertyWidget and VecPropertyWidget configure their adjusters to
display as many decimals as their properties have significant decimal
places. Moreover, they connect to the s_decimalsChanged signal in order
to reconfigure their adjusters when the number of significant decimal
places of their properties changes.

Floating point properties were previously typedef'd to specific
instantiations of NumericProperty. Now that we have
FloatingPointProperty, which extends NumericProperty to control how many
decimal places should be shown when displaying the property's value, all
typedefs for floating point properties have been updated to point to it
instead.

As a result, many processors and pipelines needed to have their includes
and/or constructors fixed to import and work with the new typedefs.