- 01 Mar, 2017 1 commit
-
-
Jakob Weiss authored
* minor whitespace fix in mainwindow.cpp
-
- 29 Sep, 2016 1 commit
-
-
Jakob Weiss authored
* InspectorWindow immediately detaches from the MDI surface * some swapBuffers warning on first creation of the inspector remains
-
- 20 Jan, 2016 1 commit
-
-
Christian Schulte zu Berge authored
* Fixed deadlock in VolumeRenderer when changing the RaycastingProcessor * Fixed compile error in ITK module * Fixed some gcc warnings * Fixed usage of deprecated ScopedSynchronousGlJobExecution in mainwindow.cpp
-
- 15 Jan, 2016 1 commit
-
-
Christian Schulte zu Berge authored
* Updated all CMake scripts to use Qt5 * CampvisApplication takes care of moving the QGLContext thread affinity to the threads that do the rendering. * QtCanvas:resize() is called through Qt signalling to ensure being in GUI thread. * Added init and deinit functions to the Runnable interface. * minimum required CMake version is now 3.0 refs #249
-
- 27 Jul, 2015 1 commit
-
-
Christian Schulte zu Berge authored
refs #643
-
- 23 Jul, 2015 2 commits
-
-
Christian Schulte zu Berge authored
Added Lua bindings for ProcessorFactory and PipelineFactory. Updated signature of CampVisApplication::addPipeline(), removed redundant pipeline name parameter. refs #643
-
Christian Schulte zu Berge authored
Added a field _pipelineName to AutoEvaluationPipeline. This allows to implement AutoEvaluationPipeline::getName() so that AutoEvaluationPipeline is no longer abstract. Consequently, the LuaPipeline is no longer needed. This change was also used to change the AbstractPipeline constructor signature to pass-by-reference instead of pass-by-pointer for the pipeline's DataContainer. This presents the semantics more clearly since the DataContainer must not be 0.
-
- 21 Jul, 2015 4 commits
-
-
Christian Schulte zu Berge authored
* Added default values to GenericProperty<T> * Lua export now checks properties for default values and only sets the property if its value is different from the default value.
-
Christian Schulte zu Berge authored
Moved the lua variable inspector tree widget into a separate dock on the right hand side in MainWindow. refs #643
-
Christian Schulte zu Berge authored
The FULL_MODEL represents the entire data tree as it exists in the Lua VM. The COMPLETER_MODEL collapses the tables to a representation only containing tables and their corresponding SWIG instance methods. This allows the CompletingLuaLineEdit also to show inherited methods. refs #643
-
Christian Schulte zu Berge authored
* Split up campvis-application executable into campvis-application library and campvis executable. This allows to create a Lua module for the stuff in campvis-application. * Added Lua binding stub for campvis-application * Revised LuaTable and it's offsprings to (almost) fully model the Lua table model * Added MetatableLuaTable to model Lua's metatables * LuaTable supports caching the current field state in a value map supporting lazy instantiation * Added LuaTableTreeModel transforming the LuaTable structure into a QAbstractItemModel * Extended ScriptingWidget to contain both a LuaTableTreeWidget containing a variable view as well as with a LuaCompleter automatically completing the typed Lua commands with the variables extracted from the lua state. refs #643
-
- 20 Jul, 2015 1 commit
-
-
Christian Schulte zu Berge authored
-
- 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
-
-
Jakob Weiss 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.
-