- 08 Jul, 2015 1 commit
-
-
Christian Schulte zu Berge authored
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.
-
- 02 Jul, 2015 1 commit
-
-
Christian Schulte zu Berge authored
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.
-
- 01 Apr, 2015 1 commit
-
-
Christian Schulte zu Berge authored
* Cleaned up unsused code * Fixed cppcheck issues * Fixed depth test issues during OrientationOverlay rendering (had glitches in combination with DRRRaycaster)
-
- 23 Mar, 2015 3 commits
-
-
Hossain Mahmud authored
-
Hossain Mahmud authored
-
Hossain Mahmud authored
-
- 18 Feb, 2015 2 commits
-
-
Christian Schulte zu Berge authored
* Added stretch widget to PropertyCollectionWidget
-
Declara Denis authored
Now it is possible to change the property window just by navigating the PipelineTreeWidget with the arrow keys
-
- 06 Feb, 2015 1 commit
-
-
Christian Schulte zu Berge authored
* Fixed MSVC warning in mainwindow.cpp
-
- 17 Dec, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* 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
-
- 16 Dec, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 15 Dec, 2014 1 commit
-
-
Christian Schulte zu Berge authored
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
-
- 11 Dec, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* Improved appearance of PipelineTreeWidget * Fixed IntPropertyWidget and FloatPropertyWidget recursively setting the widgets value, when the change event comes from the widget itself
-
- 10 Dec, 2014 1 commit
-
-
Hossain Mahmud authored
-
- 29 Nov, 2014 1 commit
-
-
Hossain Mahmud authored
-
- 24 Nov, 2014 1 commit
-
-
Hossain Mahmud authored
transferfunc try v2
-
- 04 Nov, 2014 1 commit
-
-
Hossain Mahmud authored
-
- 29 Oct, 2014 2 commits
-
-
Hossain Mahmud authored
Conflicts: core/bindings/campvis.i
-
Hossain Mahmud authored
-
- 28 Oct, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* 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()
-
- 23 Oct, 2014 2 commits
-
-
Christian Schulte zu Berge authored
refs #386
-
Christian Schulte zu Berge authored
refs #386
-
- 30 Sep, 2014 1 commit
-
-
CAMP C++ Builder authored
* new QtJobProcessor singleton: used to execute jobs in the Qt thread * CampvisApplication now has a map to obtain the window for a pipeline
-
- 27 Jul, 2014 2 commits
-
-
Christian Schulte zu Berge authored
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...)
-
Christian Schulte zu Berge authored
-
- 10 Jul, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* Introduced two new tgt::LogManager log levels LuaInfo and LuaError. * ScriptingWidget registers itself as logger and prints the Lua output into the console window.
-
- 02 Jun, 2014 1 commit
-
-
Christian Schulte zu Berge authored
* 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.
-
- 31 May, 2014 1 commit
-
-
Christian Schulte zu Berge authored
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.
-
- 05 May, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 15 Jan, 2014 1 commit
-
-
Christian Schulte zu Berge authored
-
- 13 Dec, 2013 1 commit
-
-
Christian Schulte zu Berge authored
* Moving to Apache 2.0 license * Updated AUTHORS.txt
-
- 10 Nov, 2013 1 commit
-
-
Artur Grunau authored
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.
-
- 02 Nov, 2013 3 commits
-
-
Artur Grunau authored
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
-
Artur Grunau authored
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.
-
Artur Grunau authored
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.
-
- 15 Oct, 2013 2 commits
-
-
Sebastian Pölsterl authored
-
Christian Schulte zu Berge authored
-
- 13 Oct, 2013 1 commit
-
-
Artur Grunau authored
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.
-
- 08 Oct, 2013 2 commits
-
-
Christian Schulte zu Berge authored
-
Christian Schulte zu Berge authored
-