GitLab

PipelineRegistry and ProcessorRegistry are now part of campvis-core. Furthermore, moved all calls to PipelineRegistrar<>/SmartProcessorRegistrar<> to a separate cpp file for each module. This way all registrations are at one central location and including headers in external projects does not lead to double registration.

This commit also removes the obsolete columbia and manualsegmentation modules.

Renamed CampvisPainter to PipelinePainter. The PipelinePainter now directly belongs to the corresponding AbstractPipeline, which also owns the pointer and takes care of creating, (de-)initializing and destroying it.

* Cleaned up unsused code
* Fixed cppcheck issues
* Fixed depth test issues during OrientationOverlay rendering (had glitches in combination with DRRRaycaster)

* Added stretch widget to PropertyCollectionWidget

Now it is possible to change the property window just by navigating
the PipelineTreeWidget with the arrow keys

* Fixed MSVC warning in mainwindow.cpp

* Workflow stages now store the visibility of pipeline canvases
* Extended PipelineFactory to also hold creator functions to create workflows
* CampVisApplication now creates and initializes workflows when launched with "-w WorkflowName" parameter

refs #13

The WorkflowControllerWidget resides as new tab on the right-hand dock area of the main window and allows to interact with an AbstractWorkflow instance.

refs #13

* Improved appearance of PipelineTreeWidget
* Fixed IntPropertyWidget and FloatPropertyWidget recursively setting the widgets value, when the change event comes from the widget itself

transferfunc try v2

Conflicts:
	core/bindings/campvis.i

* Added automatic copy of inspect.lua to binary directory to CMake build scripts
* Added AbstractPipeline::getProcessor(std::string&)
* Added ScopedSynchronousGlJobExecution guard to Lua command execution to ensure having an OpenGL context present
* Fixed ordering in CampvisApplication::deinit()

refs #386

refs #386

* new QtJobProcessor singleton: used to execute jobs in the Qt thread
* CampvisApplication now has a map to obtain the window for a pipeline

Register std::vector<DataContainer*> and std::vector<AbstractPipeline*> as Qt meta types in mainwindow.cpp to support them in Qt signals (even though I do not understand why the issue did not arise before...)

* Introduced two new tgt::LogManager log levels LuaInfo and LuaError.
* ScriptingWidget registers itself as logger and prints the Lua output into the console window.

* Implemented one single gloabel Lua VM for the entire CampVisApplication instead of one VM for each pipeline.
* The global Lua VM has a "pipelines" table/array, holding the pointers to each loaded pipeline
* ScriptingWidget support cycling through last executed commands via the arrow keys
* LuaVmState supports redirecting Lua's print() function to a custom one that uses tgt::Logmanager for printing (just as proof-of-concept). This shall later be extended to pass all Lua output to the scripting console.

With scripting enabled, the main window now has an additional scripting widget that allows to interact with a Lua VM. The current proof-of-concept implementation creates a Lua VM for every instantiated CAMPVis pipeline while the console just interacts with the first pipeline's one.
However, the Lua VM concept has to be reiterated later anyway. It may make more sense to have just a single central Lua VM for the entire application, which is shared by each pipeline.

* Moving to Apache 2.0 license
* Updated AUTHORS.txt

DataContainerInspectorWidget was previously stored in a regular dock
widget, but because of its rather large dimensions it didn't fit well in
any of the docking areas.

Put DataContainerInspectorWidget in an MdiDockableWindow and add it to
the MDI area. It fits much better there, and can still be undocked if
need be.

MdiDockableWindow has been extracted from MdiDockArea to simplify and
better structure our MDI implementation. The new class takes care of
creating all necessary representations (docked and floating window) of
widgets added to MdiDockArea and seamlessly switching between them in
response to the user's actions (window dragging, key presses, etc).

MdiDockableWindow improves our MDI implementation in two ways:
- MdiFloatingWindow and MdiDockedWindow instances shouldn't be
  interacted with directly; they're created and disposed of as needed,
  and therefore can't be used as a handle to access and modify an MDI
  window's state; MdiDockableWindow, in contrast, fits this role
  perfectly; it manages both representations of an MDI window, and as
  a result stays around as long as at least one of them is needed
- managing state transitions of many sub-windows directly in MdiDockArea
  was becoming clumsy as signal mapping and dynamic properties were
  required; having a separate widget that only has to control the state
  of one sub-window makes the code related to state transitions much
  simpler

The "Tools" submenu lists all standard docked tools offered by the
application (i.e. "Pipeline tree", "Pipeline properties", and "Log
viewer"), and lets the user toggle their visibility.

This commit adds a simple main menu to the application. For the time being
it only has 2 submenus, "File" and "Visualizations". The latter is created
by MdiDockArea and lets users manage the visibility and placement of
canvas windows.

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.