- 28 Aug, 2005 5 commits
-
-
Sebastien Barre authored
-
Sebastien Barre authored
-
Sebastien Barre authored
-
Sebastien Barre authored
-
Andy Cedilnik authored
-
- 27 Aug, 2005 6 commits
-
-
Berk Geveci authored
-
Berk Geveci authored
-
Berk Geveci authored
-
Sebastien Barre authored
-
Will Schroeder authored
ENH:Sneaking in event for point placement; allows special processing of point placements such as snap-to-grid; includes info in calldata that indicates which point is being placed
-
Andy Cedilnik authored
-
- 26 Aug, 2005 7 commits
-
-
Sebastien Barre authored
ENH: the whole preset name was probably overkill. Remove it for now (it was added couple weeks ago, no backward compat pb)
-
Brad King authored
-
Brad King authored
BUG: FILE command in PluginInstall.cmake already knows about the BUILD_TYPE so we should not set it.
-
Sebastien Barre authored
BUG: [backward compat change]. GetActiveCamera() does not reset the camera anymore. If the renderer had no camera, it would create one automatically *and* reset it. This side effect would trigger the whole pipeline to get the props bounds. Moreover, a call to GetActiveCamera()->Foobar() would have different/inconsistent results depending on whether or not the renderer had a camera already. GetActiveCamera() still creates a cam, but does not reset it. If one calls GetActiveCamera(), it should have full control of it anyway at this point (and reset it or not). The old friendly behaviour remains though, if the user does not bother with the camera at all, it is created during the first render *and* reset to show the whole scene.
-
Sebastien Barre authored
BUG: [backward compat change]. GetActiveCamera() does not reset the camera anymore. If the renderer had no camera, it would create one automatically *and* reset it. This side effect would trigger the whole pipeline to get the props bounds. Moreover, a call to GetActiveCamera()->Foobar() would have different/inconsistent results depending on whether or not the renderer had a camera already. GetActiveCamera() still creates a cam, but does not reset it. If one calls GetActiveCamera(), it should have full control of it anyway at this point (and reset it or not). The old friendly behaviour remains though, if the user does not bother with the camera at all, it is created during the first render *and* reset to show the whole scene.
-
Sebastien Barre authored
BUG: fix PrintSelf and reset camera issue. The InputConnection warning will be fixed automatically today once the whole Renderer::GetActiveCamera is fixed
-
Andy Cedilnik authored
-
- 25 Aug, 2005 20 commits
-
-
Sebastien Barre authored
-
Sebastien Barre authored
BUG: (?): GetActiveCamera would instantiate a camera, and call a ResetCamera. This would have a lot of side effects side effects (like computing the bounds of all props, which will eventually call UpdateInformation() on data objects, etc). It's old, but let's try without. Obviously can be solved by calling ResetCamera manually. // this->ResetCamera();
-
Sebastien Barre authored
-
Will Schroeder authored
-
Brad King authored
-
Brad King authored
-
Brad King authored
ENH: Added VTK_INSTALL_QT_PLUGIN_DIR cache variable to control install location of QVTKWidgetPlugin.
-
Brad King authored
ENH: Removing . from LINK_DIRECTORIES. Now that rpath/non-rpath builds are done properly we do not need it.
-
Brad King authored
-
Sebastien Barre authored
BUG: (?): GetActiveCamera would instantiate a camera, and call a ResetCamera. This would have a lot of side effects side effects (like computing the bounds of all props, which will eventually call UpdateInformation() on data objects, etc). It's old, but let's try without. Obviously can be solved by calling ResetCamera manually. // this->ResetCamera();
-
Brad King authored
This commit was manufactured during conversion from CVS to merge the end of the ParaView 2.2 release branch.
-
Amy Squillacote authored
-
Brad King authored
BUG: VTKExamplesTarget should depend on QVTK and vtkMFC libraries since some examples use these libraries.
-
Brad King authored
-
Will Schroeder authored
-
Will Schroeder authored
-
Sebastien Barre authored
BUG: the subclasses have to call the superclass Render() instead of calling the renderwindow method directly, so that the super can make sure all conditions are met to render, *and* events are called properly
-
Sebastien Barre authored
-
Brad King authored
-
Andy Cedilnik authored
-
- 24 Aug, 2005 2 commits