GitLab

# Take back the updateInfoWidget to its previous position and add a new updateColor function to just update the Color in the label.

# Add the ability to read the color when hovering the mouse into the canvas and dragging the right mouse button.

# Make a pointer from datacontainerinspectorwidget into datacontainerinspectorcanvas, as we need to call the updateInfoWidget() after updating the color.

# Make the updateInfoWidget() as public to be able to call it.

# Add the Capability to look up the color under the mouse button when one of the mouse buttons is pressed.

In its destructor, LogHighlighter first of all deleted its filter regex
explicitly, and then called `setFilterRegExp(0)`, triggering a second —
this time somewhat implicit — delete. If the filter regex pointer was
not NULL, this caused the application to crash due to a double-free.

Fix this error by not invoking `setFilterRegExp` in LogHighlighter's
destructor; the explicit delete performs the same cleanup as
`setFilterRegExp` anyways.

 * fixed 1D geometry TF editor
 * introduced OptionProperty to specify gradient computation mode
 * added s_changed signal of properties also being propagated to its shared properties
 * fixed sampling rate compensation when using adaptive sampling in simpleraycaster.frag

Fixed missing/wrong deregistration of GeometryXdTransferFcuntionEditors when their widgets are closed (and hence the GL contexts destroyed)

Fixes -Wswitch

Previously, when an MDI window was being dragged very fast and its state
changed from docked to floating (or vice versa), it wouldn't be placed
under the cursor, but instead some way behind it (with regards to the
drag direction). This happened because we decided where to place the
window's based on its last position in its previous state. Now we use
the cursor's position to calculate the window's new position, which
fixes the problem.

PipelineMdiSubWindow has been renamed MdiDockedWindow, and
refactored to make it easier to use it with arbitrary widgets.

To better group MDI-related classes, all of them have been moved to the
´gui/mdi´ directory.

VisualizationPipelineWidget has been renamed MdiFloatingWindow, and
refactored to make it easier to use it with arbitrary widgets.

VisualizationPipelineWrapper has been renamed MdiDockArea, and refactored
to make it easier to use it with arbitrary widgets. It now inherits from
QMdiArea, which removes an unnecessary layer of indirection. Moreover, it
creates MDI subwindows and floating windows only if necessary, i.e. when
a widget stored in it changes state.

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

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

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.

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.

A new attribute has been added to all numeric properties: step value. It
determines the value of a single increment/decrement that numeric
property widgets use when their associated properties are modified using
sliders or spin boxes (users are still able to type any valid property
value in text edits).

Numerous processors and pipelines had to be updated to work with the
changed NumericProperty interface. However, choosing a well-suited step
value for each property can make it easier for users to modify the
property — using one step value for all properties leads to cases where
it is either too small, causing users to go through property values
which don't cause any visible change, or too big, making it difficult to
quickly determine the right property value.

Previously, widgets for int and vector<int> properties used only spin
boxes to display and let users modify the values of their associated
property.

Now that we have IntAdjusterWidget, IntPropertyWidget and all
IVecPropertyWidgets have been updated to use it to make it possible to
change the values of their components with not only a spin box, but also
a slider.

IntAdjusterWidget displays and provides two ways of modifying integers:
a slider that can be used to quickly change numeric values, and a spin
box, which is better suited for precise adjustments.

IntAdjusterWidget is a simple extension of AbstractAdjusterWidget<int>.
It is designed to be used by IntPropertyWidget and widgets for vector
properties storing integers.