GitLab

Depending on StringProperty's display type, its property widget shows either just the QLineEdit, or additionally a browse button that pops up a QFileDialog for either loading or saving a file, or choosing a directory.

closes #43

To now, each property hat an _invalidationLevel field that was evaluated by processors when the property had changed in order to determine what has to be done. However, since properties could also be owned by other classes, this design was semantically misleading.
Therefore, it was removed with this commit and replaced by the invalidation map of each processor. Now, this per-processor mapping of property -> invalidation level is managed by the processor itself. Furthermore, the invalidation level is no longer setup during property creation but during AbstractProcessor::addProperty(), which also makes much more sense.

ATTENTION: Due to these intrusive API changes, the code of all processors and other classes handling properties needs to be changed. As a reminder, the implementation of addProperty() also now takes a reference instead of a pointer, so that old code does no longer compile.

refs #542

Fixed TrackballNavigationEventListener setting the window ratio of its CameraProperty being directly overwritten due to concurrent access.

Builds and runs fine so far, but no elaborate testing done yet. Compiler throws a bunch of C4275 warning, since sigslot:has_slots<> is used in exported classes but is itself not exported. While this is no direct problem for campvis-internal builds, it should still be fixed some time.

refs #377

Added s_propertyAdded and s_propertyRemoved signals to PropertyCollection signaling changes to the property list. PropertyCollectionWidget listens to them and updates the GUI on the fly.

* Fixes #362: assignment used instead of comparison
* slight update in GlMorphologyFilter

* RaycastingProcessor now has the p_targetImageID property and optionally uses a custom GLSL version for the shader
* Introducing PropertyCollection::getNestedProperty allowing to get nested properties with a single method call
* Fixed StringUtils::split() methods being broken with multi-character delimiters

Refactoring AbstractProcessor::process() for clearer semantics and better and more uniform handling of invalidation levels:
 * AbstractProcessor::process() now calls updateShader(), updateProperties() and/or updateResult() with respect to the current invalidation level
 * each processor shall no longer override process() but the updateXYZ() methods, at minimum updateResult()
 * AbstractProcessor::process() takes care of (un)locking the processor itself (no need to do this from the outside anymore)

Further implicit changes:
 * Removed redundant HasPropertyCollection::updateProperties()

Completely moved the image data handle and histogram computation from the TF to the TF property. Histogram computation is now thread safe.

Started refactoring the TransferFunctionProperty: The optional ImageData handle will be stored in the TF property instead of the TF itself. Furthermore, the property now supports automatically fitting the TF window to the image data.

* Moving to Apache 2.0 license
* Updated AUTHORS.txt

+ update the get function of abstractproperty.h and abstractproperty.cpp to support the const objects.

- Still sufring from invalid enumerator in meshgeomtery rendering.

reverted changes from e7b11bfa: "added s_changed signal of properties also being propagated to its shared properties"
This was weak design and lead to problems with the AutoEvaluationPipeline.

 * 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

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)

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.

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.

FloatingPointProperty extends NumericProperty to control how many
decimal places should be shown when displaying the property's value. For
that reason, it stores information about the number of significant
decimal places of each of its components.

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.

* Introducing DataNamePropertyWidget offering a combo box with all DataHandles in current DataContainer
* added slice rendering to Columbia1 pipeline

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@516 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@510 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

some minor fixes

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@504 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@489 bb408c1c-ae56-11e1-83d9-df6b3e0c105e

* fixed DataNameProperty not updating shared properties when being notified

git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@485 bb408c1c-ae56-11e1-83d9-df6b3e0c105e