https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Aneeman&feedformat=atomKitwarePublic - User contributions [en]2024-03-28T12:23:48ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=VTK_Classes&diff=44764VTK Classes2012-01-06T15:17:09Z<p>Aneeman: </p>
<hr />
<div><small>This page was based on Sebastien Barre's [http://www.barre.nom.fr/vtk/links-classes.html VTK Links: Classes] page</small>.<br />
<br />
Have you written your own VTK C++ classes on top of the VTK core ? Here are some of them, but feel free to send me any links to your own work : extending the VTK functionalities helps ! Don't forget to check: [http://www.vtk.org/Wiki/VTK/Developers_Corner How to Contribute], the [http://public.kitware.com/VTK/contribute.php#coding-standards Coding Standards] and the [http://public.kitware.com/VTK/copyright.php Copyright Information] :)<br />
<br />
== C++ ==<br />
<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Ejshalf/VTK/vtkOffScreen/ vtkOpenGLOffscreenRenderWindow]<br />
<br />
''(J. Shalf)''<br />
"Use in place of a vtkRenderWindow to draw an offscreen image. This is specifically for Unix/OpenGL/X11 systems. [...] For SGI systems, it will use pbuffers for hardware accelerated offscreen rendering. For all other architectures, it will use GLX pixmaps which tend to be software-rendering (except for hardware-accelerated Mesa)."<br />
<br />
[http://www.imaging.robarts.ca/~glehmann/OffScreen/OffScreen.html vtkXOpenGLOffScreenRenderWindow]<br />
''(Glen Lehmann)''<br />
"Glen Lehmann has updated John Shalf's above code to work with more recent versions of VTK."<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Ejshalf/VTK/vtkHDFReader/ vtkHDFReader]<br />
''(J. Shalf)''<br />
"HDF4 is a self-describing platform independent binary file format for storing Scientific Datasets. [...]. It also interoperates with the Unidata NetCDF standard. The vtkHDFReader is able to read HDF-SDS (Scientific Dataset) files into vtk as well as some versions of NetCDF data."<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Ejshalf/VTK/vtkSMP/ vtkSMP]<br />
<br />
''(J. Shalf)''<br />
"This is a slowly growing collection of vtk filters that are being parallelized for Shared Memory Processor (SMP) architectures. The target audience is people who have very large datasets and computers with large numbers of processors and want to accelerate operations like streamlines and contour filters in order to maintain interactive performance."<br />
<br />
vtkIVImporter<br />
<br />
''(S. Desmet)''<br />
The class vtkIVImporter is capable to import most VRML1.0 or Inventor1.0 scenes. The lex and yacc files come from an existing VRML1.0 syntax checker. Code was incorporated to generate the necessary vtk structures.<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Emahall/ vtkOrthoSlicer]<br />
<br />
''(M. Hall)''<br />
"A small, fast orthogonal slicer for vtkStructuredPoints datasets. It has the following advantages: 1)There are no extents or odd things to set (it uses the dimensions of the input to determine the dimensions of the slice plane). 2)To use it, you set the input, set the plane normal (x,y, or z axes) and set the x,y, or z coordinate of the plane. 3) It has 2 modes of output: Triangle strips and Quads (actually, polygons)."<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Emahall/ vtkSMG]<br />
<br />
''(M. Hall)''<br />
"(Simple Multi Grid) This package is intended to make multigridded datasets (i.e. collections of native vtk dataset types, most importantly StructuredPoints ) into first class datatypes. Only a simple prototype is availible now, however the non-"Simple" version will have the ability to associate a structure with an MGDataset (For dealing with simple collections of boxes, AMR datasets, or hierarchical collections), thus allowing (specially written) filters to take advantage of any inherent structure in the data. Threading will be added at a later date. "<br />
<br />
[http://www.cineca.it/visit/devel/vtk/vtkClasses.html Classes @ CINECA]<br />
<br />
''(CINECA)''<br />
Various classes : Image Packing/Unpacking, Image Processing, Import/Export, Geometric Tools, Math.<br />
<br />
[http://gdcm.sf.net/ vtkGDCMImageReader/vtkGDCMImageWriter]<br />
<br />
''(Mathieu Malaterre and al.)''<br />
GDCM -which stands for Grassroots DiCoM- is yet another C++ library dedicated to reading/parsing and writing Dicom files. <br />
* offer DICOM jpeg compressed image support,<br />
* enable DICOM header parsing of sequences and overlays,<br />
* distribute a VTK thin wrapper of gdcm (essentially a vtkGDCMImageReader).<br />
<br />
[http://www.vtk.org/Wiki/images/7/77/VtkPointNormalColorReader.zip vtkPointNormalColorReader]<br />
<br />
''David Doria''<br />
<br />
[http://www.cmake.org/Wiki/images/3/31/VtkOFFReader.zip vtkOFFReader]<br />
<br />
''David Doria''<br />
<br />
== wxWidgets (previously wxWindows) ==<br />
<br />
[http://sourceforge.net/projects/wxvtk/ wxVTK - Yet Another Port of wxVTKRenderWindowInteractor]<br />
<br />
''(M. Malaterre)''<br />
"This class enable VTK to render to and interact with wxWindows just as any wxWindow component.<br />
wxVTKRenderWindowInteractor provide a VTK widget for wxWindow. This class was completely rewrote to have the Look & Feel of the python version."<br />
<br />
== gtk2 ==<br />
<br />
[http://imagic.weizmann.ac.il/~dov/freesw/gtk/vtkgtk vtkgtk - an vtk interactor class in gtk]<br />
<br />
''(Dov Grobgeld)''<br />
"This is a vtk interactor for gtk2. The class is called vtkGtkRenderWindowInteractor<br />
which inherits from vtkRenderWindowInteractor. It seems to work nicely, though the interactor <br />
should really be turned into a proper GtkWidget."<br />
<br />
[http://sourceforge.net/projects/vtkmm vtkmm - a small library for using vtk with gtkmm-2.4]<br />
<br />
''(Matthias Langer)''<br />
"vtkmm should make it easy to write applications using [http://www.gtkmm.org/ gtkmm] for the gui <br />
and vtk for visualisation. Generally speaking, vtkmm gives you a class derived from Gtk::DrawingArea which contains<br />
a vtkRenderer and a vtkRenderWindow, both accessible from the outside. To compensate the fact that <br />
vtkRenderWindowInteractor doesn't seem to work with gtk, the class implements its own interactive<br />
behavour. Please note that the API of the library is at the moment open for discussion and may <br />
therefore change."<br />
<br />
== Qt ==<br />
<br />
QVTK: As of 01/28/2005 Qt support is now part of VTK for X11(OpenGL and Mesa), Windows and the Mac platforms.<br />
Qt versions 3 and 4 are both supported. For more information, go to the [http://vtk.org/cgi-bin/viewcvs.cgi/GUISupport/Qt CVS GUISupport/Qt], and also some [http://vtk.org/cgi-bin/viewcvs.cgi/Examples/GUI/Qt/ examples] are provided. This Qt code is [http://www.trolltech.com/products/3rdparty/vtksupport.html free] to use with both commercial and free versions of Qt. It also contains a Qt designer plugin for putting this widget into the designer. Developers wishing to contribute changes into the VTK CVS repository must have a commercial Qt license to prevent from tainting the BSD-style open source license (see code and README for details).<br />
<br />
[http://www.medinf.mu-luebeck.de/%7Eehrhardt/vtkQGL/vtkQGL.html vtkQGL - bringing VTK and Qt together] link is dead use: [http://web.archive.org/web/ web archive]<br />
<br />
''(J. Ehrhardt)''<br />
vtkQGL provides C++ classes to render your VTK data in a Qt widget. Surface rendering and volume rendering is supported, and now some classes for image display are added. Qt is a fully object-oriented multi-platform GUI toolkit.<br />
<br />
[http://vtkqgl.sourceforge.net/ vtkQGL : QT RenderWindow and RenderWindowInteractor Classes for VTK]<br />
<br />
''(M. P. Pagey)''<br />
This package contains two classes vtkQGLRenderWindow and vtkQGLRenderWindowInteractor which allow one to use VTK with the QGLWidget extension of Qt. In other words, these classes can be used to build Qt applications which utilize the facilities provided by the VTK libraries ; "It should work with both VTK-2.4 and VTK-3.1.2. It also has full GNU autoconf based installation. It does not use any X-windows specific code and hence should work with Microsoft Windows [...]".<br />
<br />
[http://www.matthias-koenig.net/vtkqt/ vtkQt]<br />
<br />
''(M. Koenig. )''<br />
The vtkQt classes combine VTK and Qt(TM) for X11.<br />
<br />
[http://www.medres.ch/%7Ejstifter/vtkandqt/index.html VTK and QT] link is dead use: [http://web.archive.org/web/ web archive]<br />
<br />
''(J. Stifter)''<br />
This package combines vtk and qt together ; "The package is small and simple (800 lines of code), documented with doxygen, flexible to use (dynamic definitons, mouse button) and has been tested on win32, linux, SGI IRIX, IBM RS6000 AIX. It should run on every system, which compiles vtk and qt.".<br />
<br />
[http://staff.science.uva.nl/~dshamoni/VtkQt/ VtkQt]<br />
<br />
''( Denis P. Shamonin)''<br />
The VtkQt library has widgets for rendering OpenGL graphics. VtkQt provides functionality for displaying Vtk+OpenGL graphics integrated into a Qt application.<br />
<br />
[http://wwwipr.ira.uka.de/~kuebler/vtkqt/ VTK_QT]<br />
<br />
''(Carsten Kübler)''<br />
MeGI's VTK_QT solution by Carsten Kübler. Dynamic use of the object factory.<br />
<br />
== FLTK ==<br />
<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Ejshalf/VTK/vtkFlRenderWindow/ vtkFlRenderWindow] link is dead use [http://web.archive.org/web/ web archive]<br />
<br />
''(J. Shalf)''<br />
"vtkFlRenderWindow extends FLTK's ability to embed OpenGL drawing areas into GUI's so that a vtkRenderWindow can be integrated with an FL user interface [...] The Fast Light Toolkit (FLTK) is a really nifty little cross-platform GUI framework which is complete with a little GUI builder called Fluid."<br />
<br />
[http://cpbotha.net/vtkFlRenderWindowInteractor.html vtkFlRenderWindowInteractor]<br />
<br />
''(C. P. Botha)''<br />
"vtkFlRenderWindowInteractor is a VTK class [...] that enables VTK to render to and interact with your FLTK application."<br />
<br />
[http://vtkfltk.sourceforge.net/ vtkFLTK]<br />
<br />
''(Sean McInerney)''<br />
"vtkFLTK is a small C++ class library for development of FLTK event-driven interfaces for use with VTK. vtkFLTK bridges disparities between FLTK and VTK event and windowing system handling. Its use is made magically simple via VTK's Instantiator and Factory mechanisms as well as the CMake build system. See the copious examples for usage details."<br />
<br />
== CAVE ==<br />
<br />
<br />
[http://brighton.ncsa.uiuc.edu/%7Eprajlich/vtkActorToPF/ Multipipe Rendering in A CAVE using Performer and vtkActorToPF]<br />
<br />
''(P. Rajlich, NCSA)''<br />
"The idea is that you can compute geometry using VTK and render using Iris Performer. The advantage of doing so is that there are some things that VTK hasn't been designed for, such as rendering to multiple channels (i.e. multi-headed displays such as the CAVE here at NCSA). Using vtkActorToPF, you can write interactive visualization applications for such environments without much trouble. Performer is a Silicon Graphics rendering library that also provides other features not found in VTK such as scene-graphs and intersection testing."<br />
<br />
[http://zeus.ncsa.uiuc.edu/%7Emahall/ vtk2CAVE] link is dead use [http://web.archive.org/web/ web archive]<br />
<br />
''(M. Hall)''<br />
"This small collection of files enables one to display a vtkActor in a CAVE/ Immersadesk/ I-Wall, etc. with a very small amount of work. It is very stable, very easy to use, and has a built in shared mem. buffering scheme which means that you can use dynamic vtkActors without writing your own double buffering code. Caveats are that it does not yet support vtkCameras, Lights, or Texture Maps, but if there is enough demand, these features can be added fairly easily."<br />
<br />
[http://staff.science.uva.nl/~dshamoni/VtkCave/ VtkCave]<br />
''(Denis P. Shamonin)''<br />
The classes in this library provide an interface for VTK programs to render in virtual environments maintained by VRCO's CAVE library. VtkCave is a cross-platform software development system for building high-performance, real-time, integrated 3D immersive applications.<br />
<br />
== FOX ==<br />
<br />
<br />
[http://donguri.sakura.ne.jp/%7Eshock8/fox/fox_vtk/ FXVTKWindow]<br />
<br />
''(shock8)''<br />
"FXVTKWindow is a FOX-GUI renderering window widget class for the exceeding visualization library VTK."<br />
<br />
[http://www.brilligent.com/wikka.php?wakka=VtkFox vtkFOX]<br />
<br />
''(D. Henry)''<br />
"FOX/VTK canvas widget and interactor to allow VTK to interact with your FOX application. Allows VTK to render inside a FOX application via the FXGLCanvas control. Keyboard and mouse events are translated to allow for "native" VTK functionality. Source includes examples."<br />
<br />
== Cocoa (Mac OS X) ==<br />
<br />
[http://www.rogue-research.com/vtk/SimpleCocoaVTK.html SimpleCocoaVTK]<br />
<br />
''(Sean McBride)''<br />
"SimpleCocoaVTK is a simple example intended to show how to use vtk in a Mac-only Cocoa application using Xcode 2.2. The class vtkCocoaGLView is a subclass of NSView and you can use it like pretty much any other NSView."<br />
<br />
{{VTK/Template/Footer}}</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=44759VTK/Developers Corner2012-01-05T23:32:10Z<p>Aneeman: /* Creating, Compiling and Testing a New Class */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<br />
<source lang="cpp"><br />
vtkTypeMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
* Accidentally using the old vtkTypeRevisionMacro instead of vtkTypeMacro will result in extremely confusing vtable errors!<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.<br />
<br />
== Creating a New VTK Class ==<br />
<br />
You can start by renaming an existing class, than changing it to do what you would like. For example, I want to make a new class named vtkReynoldsGlyph, which is similar to vtkTensorGlyph.<br />
<br />
'''Creating and Compiling Steps:''' <br />
<br />
# Copy vtkTensorGlyph.h to vtkReynoldsGlyph.h and modify the class name within the new header file.<br />
# Copy vtkTensorGlyph.cxx to vtkReynoldsGlyph.cxx and modify the new class's scoping name for each method, e.g. vtkReynoldsGlyph::vtkReynoldsGlyph() for the constructor and so on.<br />
# Edit CMakeLists.txt in that directory; add your class's name.<br />
# Rerun<br />
<br />
$ ccmake /path/to/source <br />
<br />
(Running ccmake will create a new make file that includes your new class).<br />
# Then run <br />
<br />
$ make<br />
<br />
The make process will create tcl wrappers for you.<br />
<br />
'''Testing Your new class'''<br />
<br />
If there is an existing test for the class you modified to make your class, you can just edit it to create your an instance of your new class instead of the old one. Or you can write your own test in tcl.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=44758VTK/Developers Corner2012-01-05T23:30:10Z<p>Aneeman: /* Creating, Compiling and Testing a New Class */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<br />
<source lang="cpp"><br />
vtkTypeMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
* Accidentally using the old vtkTypeRevisionMacro instead of vtkTypeMacro will result in extremely confusing vtable errors!<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.<br />
<br />
== Creating, Compiling and Testing a New Class ==<br />
<br />
You can start by renaming an existing class, than changing it to do what you would like. For example, I want to make a new class named vtkReynoldsGlyph, which is similar to vtkTensorGlyph.<br />
<br />
'''Creating and Compiling Steps:''' <br />
<br />
# Copy vtkTensorGlyph.h to vtkReynoldsGlyph.h and modify the class name within the new header file.<br />
# Copy vtkTensorGlyph.cxx to vtkReynoldsGlyph.cxx and modify the new class's scoping name for each method, e.g. vtkReynoldsGlyph::vtkReynoldsGlyph() for the constructor and so on.<br />
# Edit CMakeLists.txt in that directory; add your class's name.<br />
# Rerun<br />
<br />
$ ccmake /path/to/source <br />
<br />
(Running ccmake will create a new make file that includes your new class).<br />
# Then run <br />
<br />
$ make<br />
<br />
The make process will create tcl wrappers for you.<br />
<br />
'''Testing Your new class'''<br />
<br />
If there is an existing test for the class you modified to make your class, you can just edit it to create your an instance of your new class instead of the old one. Or you can write your own test in tcl.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=44757VTK/Developers Corner2012-01-05T23:28:45Z<p>Aneeman: /* Creating, Compiling and Testing a New Class */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<br />
<source lang="cpp"><br />
vtkTypeMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
* Accidentally using the old vtkTypeRevisionMacro instead of vtkTypeMacro will result in extremely confusing vtable errors!<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.<br />
<br />
== Creating, Compiling and Testing a New Class ==<br />
<br />
You can start by renaming an existing class, than changing it to do what you would like. For example, I want to make a new class named vtkReynoldsGlyph, which is similar to vtkTensorGlyph.<br />
<br />
'''Creating and Compiling Steps:''' <br />
<br />
# Copy vtkTensorGlyph.h to vtkReynoldsGlyph.h and modify the class name within the new header file.<br />
# Copy vtkTensorGlyph.cxx to vtkReynoldsGlyph.cxx and modify the new class's scoping name for each method, e.g. vtkReynoldsGlyph::vtkReynoldsGlyph() for the constructor and so on.<br />
# Edit CMakeLists.txt in that directory; add your class's name.<br />
# Rerun ccmake /path/to/source (Running ccmake will create a new make file that includes your new class).<br />
# Then run make<br />
<br />
The make process will create tcl wrappers for you.<br />
<br />
'''Testing Your new class'''<br />
<br />
If there is an existing test for the class you modified to make your class, you can just edit it to create your an instance of your new class instead of the old one. Or you can write your own test in tcl.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=44756VTK/Developers Corner2012-01-05T23:27:28Z<p>Aneeman: /* Creating, Compiling and Testing a New Class */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<br />
<source lang="cpp"><br />
vtkTypeMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
* Accidentally using the old vtkTypeRevisionMacro instead of vtkTypeMacro will result in extremely confusing vtable errors!<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.<br />
<br />
== Creating, Compiling and Testing a New Class ==<br />
<br />
You can start by renaming an existing class, than changing it to do what you would like. For example, I want to make a new class named vtkReynoldsGlyph, which is similar to vtkTensorGlyph.<br />
<br />
'''Creating and Compiling Steps:''' <br />
<br />
# Copy vtkTensorGlyph.h to vtkReynoldsGlyph.h and modify the class name within the new header file.<br />
# Copy vtkTensorGlyph.cxx to vtkReynoldsGlyph.cxx and modify the new class's scoping name for each method, e.g. vtkReynoldsGlyph::vtkReynoldsGlyph() for the constructor and so on.<br />
# Edit CMakeLists.txt in that directory; add your class's name.<br />
# Rerun ccmake /path/to/source<br />
# Then run make<br />
<br />
The make process will create tcl wrappers for you.<br />
<br />
'''Testing Your new class'''<br />
<br />
If there is an existing test for the class you modified to make your class, you can just edit it to create your an instance of your new class instead of the old one. Or you can write your own test in tcl.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=44755VTK/Developers Corner2012-01-05T23:25:15Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<br />
<source lang="cpp"><br />
vtkTypeMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
* Accidentally using the old vtkTypeRevisionMacro instead of vtkTypeMacro will result in extremely confusing vtable errors!<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.<br />
<br />
== Creating, Compiling and Testing a New Class ==<br />
<br />
You can start by renaming an existing class, than changing it to do what you would like. For example, I want to make a new class named vtkReynoldsGlyph, which is similar to vtkTensorGlyph.<br />
<br />
'''Creating and Compiling Steps:''' <br />
<br />
# Rename vtkTensorGlyph.h to vtkReynoldsGlyph.h and modify the class name within the file.<br />
# Rename vtkTensorGlyph.cxx to vtkReynoldsGlyph.cxx and modify the class's scoping name for each method, e.g. vtkReynoldsGlyph::vtkReynoldsGlyph() for the constructor and so on.<br />
# Edit CMakeLists.txt in that directory; add your class's name.<br />
# Rerun ccmake /path/to/source<br />
# Then run make<br />
<br />
The make process will create tcl wrappers for you.<br />
<br />
'''Testing Your new class'''<br />
<br />
If there is an existing test for the class you modified to make your class, you can just edit it to create your new class instead of the old one. Or you can write your own test in tcl.<br />
<br />
You can edit an exist<br />
VTK/Graphics/vtkTensorGlyph.cxx to VTK/Graphics/vtkReynoldsGlyph.cxx</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39955VTK/Developers Corner2011-05-17T16:44:44Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39954VTK/Developers Corner2011-05-17T16:44:05Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html) or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39953VTK/Developers Corner2011-05-17T16:43:40Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html)<br />
<br />
or clone the repository directly from git.<br />
<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39952VTK/Developers Corner2011-05-17T16:42:54Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html)<br />
or clone the repository directly from git.<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39951VTK/Developers Corner2011-05-17T16:42:19Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html)<br />
or<br />
clone the repository directly from git.<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39950VTK/Developers Corner2011-05-17T16:41:41Z<p>Aneeman: /* Setting Up A Development Environment */</p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html)<br />
or<br />
clone the repository directly from git.<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39949VTK/Developers Corner2011-05-17T16:40:04Z<p>Aneeman: </p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
<br />
== Setting Up A Development Environment ==<br />
<br />
First things, get on the vtk and or paraview mailing lists.<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
http://www.vtk.org/mailman/listinfo/paraview<br />
That is the best place to ask questions since you get many eyes on the<br />
problem. The best way to search said lists is via<br />
markmail.org (of course you can do it via google too but I can't<br />
remember the exact expression to ask google to do it well).<br />
<br />
Second, I recommend working at the VTK level if possible. That<br />
simplifies the learning curve a bit, makes the work reusable by a<br />
larger group of people, and also because there is a fairly standard<br />
way to expose VTK code in ParaView. (See<br />
http://paraview.org/Wiki/Plugin_HowTo and<br />
http://pluginwizard.mirarco.org/)<br />
<br />
As for setting up a development environment:<br />
1) installing cmake (http://www.cmake.org/cmake/resources/software.html)<br />
2) either downloading a source tarball<br />
(http://www.vtk.org/VTK/resources/software.html)<br />
or<br />
clone the repository directly from git.<br />
$ git clone git://vtk.org/VTK.git VTK<br />
$ cd VTK<br />
$ ./Utilities/SetupForDevelopment.sh<br />
I recommend using git since, although it takes longer to learn it<br />
makes it easier to keep track of your changes and makes it easier to<br />
eventually contribute the code back in.<br />
3) use cmake to configure a build environment in some other directory<br />
and then run make or visual studio to do the actual compilation. I<br />
suggest turning on the extra warnings and VTK_DEBUG_LEAKS flags to<br />
help catch problems early on.<br />
4) I recommend building a test stub for your code starting from one of<br />
the existing tests. Turning on python wrappings and writing the test<br />
in python can make for very quick development.<br />
<br />
Notes:<br />
After you create your class somewhere in VTK, to get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.<br />
Start by changing another class that uses the same data you are interested in.</div>Aneemanhttps://public.kitware.com/Wiki/index.php?title=VTK/Developers_Corner&diff=39919VTK/Developers Corner2011-05-16T22:02:32Z<p>Aneeman: </p>
<hr />
<div>==Dashboard submissions==<br />
===Turn on warnings===<br />
Be sure to set CMAKE_CXX_FLAGS to<br />
<source lang="text"><br />
-Wunused -Wshadow -Wformat<br />
</source><br />
<br />
===Running tests locally===<br />
To run all of the tests on your modified source tree, simply type<br />
<source lang="text"><br />
ctest<br />
</source><br />
in your build directory. This will not submit anything to the dashboard, but it is a good "first test" to simply see, locally, if everything works.<br />
<br />
===Submitting an experimental build to the dashboard===<br />
The idea of this type of submission is simply to have a nice way to view the output of all the tests, and to leave "proof" that you indeed tested the code. This is useful if you then commit your code and it breaks someone else's build - you can then claim you did everything you could :). To run this type of submission, simply type<br />
<source lang="text"><br />
make Experimental<br />
</source><br />
from your build directory.<br />
<br />
===Creating a 'Nightly' dashboard submission===<br />
It is impossible for developers to test code on every operating system, compiler, and configuration. By creating a dashboard submission, you can help them find bugs that could be affecting many users but are transparent to some developers. The idea is to get the latest source code, compile it, and run a battery of tests - reporting any compile, build, and test errors to a system which very neatly arranges the results (http://www.cdash.org/CDash/index.php?project=VTK).<br />
<br />
It is recommended to not use the same build you work with daily for you dashboard submission. If there is a problem with the nightly cvs, your code may not compile the next day!<br />
<br />
To get started, create a new directory called /home/username/Dashboards/VTK. It does not actually have to be in this exactly directory, but this path will be used throughout this example to make the ideas concrete. cd to your new directory and run these commands to check out an initial version of VTK and data sets used for testing.<br />
<br />
[[Example CMake Dashboard file|Here]] is an example cmake dashboard file.<br />
<br />
You will probably want to submit a dashboard every night, so you can add a cronjob. Run 'crontab -e' and enter the following command<br />
<source lang="text"><br />
0 1 * * * export DISPLAY=:0.0 ; ctest -S /home/username/Dashboards/VTK/dashboard.cmake -V > /home/username/Dashboards/VTK/dashboard.log 2>&1<br />
</source><br />
<br />
This says "at 1:00 AM, every day, every month, run the dashboard tests and log verbose output to dashboard.log". The DISPLAY variable is set to allow the tests that need an X server to complete successfully.<br />
<br />
== Developers Corner ==<br />
* [[Documentation Rules]]<br />
* [[TestingGuidelines]]<br />
<br />
===General Tips===<br />
* If you work with Paraview and VTK, the recommended procedure is to use the same source tree for both projects. That is, build Paraview from .../src/Paraview and VTK from .../src/Paraview/VTK.<br />
<br />
* You should use vtkGetObjectMacro and vtkCxxSetObjectMacro to set and get member variables that are custom types. This allows VTK's mechanisms to keep the reference count correct by automatically registering and unregistering your objects. An example using a custom class member variable is [[Using a custom class member variable|here]].<br />
<br />
===Pitfalls===<br />
* When using the Set*Macro's, you must initialize the variable that is being set in the constructor. The Set*Macro does a check to see if the value has changed before changing it (so that it can update the Modified variable), so if the value is uninitialized, this will cause an error in some memory checking tools (such as valgrind).<br />
* When trying to use an abstract class, such as<br />
<source lang="cpp"><br />
vtkSmartPointer<vtkPointSet> PointSet = vtkSmartPointer<vtkPointSet>::New();<br />
</source><br />
you will see <br />
error: invalid conversion from 'vtkDataObject*' to 'vtkPointSet*'<br />
<br />
To fix this, use a subclass instead.<br />
* You are getting <br />
Generic Warning: In /home/doriad/src/ParaView3/VTK/Common/vtkDebugLeaks.cxx, line 296<br />
Deleting unknown object: vtkObject<br />
<br />
and<br />
vtkDebugLeaks has detected LEAKS!<br />
Class "vtkYourClass" has N instances still around.<br />
<br />
This could mean one of two things. Either 1) you are actually doing something wrong by trying to manually delete a smart pointer or the equivalent or 2) You have forgotten to add:<br />
<source lang="cpp"><br />
vtkCxxRevisionMacro(vtkYourClass, "$Revision: 1.1 $");<br />
</source><br />
to your .cxx file and<br />
<br />
<source lang="cpp"><br />
vtkTypeRevisionMacro(vtkYourClass,vtkObject);<br />
</source><br />
to your .h file.<br />
<br />
You must do this because vtkDebugLeaks uses the VTK factory mechanism to keep track of references.<br />
<br />
<br />
* [[Simple object class]]<br />
To get your code to compile, edit CMakeLists.txt and add your cxx class filename to the file.</div>Aneeman