User:Barre/Slicer

A few notes about Slicer 3.0

• I updated the CMakeLists.txt to match the changes in KWWidgets
• Slicer3 Would not compile for Windows in shared mode, because VTK_SLICER_BASE_EXPORT was missing in all headers in Base/GUI; BTW there is a VTK_SLICER_BASE_LOGIC_EXPORT inside Base/Logic, and VTK_SLICER_BASE_EXPORT in the parent dir. I introduced a new one in the same using VTK_SLICER_BASE_GUI_EXPORT, but we/you have to make sure we/you want a unique one for each sub-lib (which is the case for each VTK packages for example, say VTK_HYBRID_EXPORT for the Hybrid package), or a global one (which was the case some time ago in VTK, with a unique VTK_EXPORT). Also, you do not need to prefix the symbol with VTK_ anymore, SLICER_BASE_EXPORT is fine.
• A set of useful setup paths scripts are automatically created using KWWidgets macros: check your bin directory for Slicer3SetupPaths.bat (or .sh, .csh), source them so that you can run Slicer3 executable when built in shared lib mode. Without this script, it becomes pretty nightmarish to setup both the PATH, TCLLIBPATH, LD_LIBRARY_PATH (which name can change) alltogether (especially since it seems the libraries in Slicer3 are in lib/, not in bin/ where the executables are; very Win32 unfriendly :)). This set of scripts do that for you, point to the right ITK, VTK and KWWidgets lib and bin dirs, set the TCLLIBPATH, etc.
• I ran Slicer3.exe, but a lot of warnings are issues because the pipeline is not setup correctly. Also, it crashed on exit, I fixed it, but this is something interesting actually: the Slicer app was listening to a ModifiedEvent in order to update its UI; the trick here is that nothing prevents a class destructor to use something like this: this->SetUserCommand(NULL);, which deallocates the UserCommand string if it was defined using the very common vtkSetStringMacro and vtkGetStringMacro in its header. What this means is you may be called back during an object destruction ! Now as long as you carefully check that the object still exist (and that should be a good practice anyway), you should be OK. I would recommend listening to more specific events though.
• Slicer3.exe would still crash on ~vtkSlicerApplicationGUI because this->KWApplication was probably deleted multiple times. I will get back to it later on, but the KWApplication that is very confusing in the current design: remember that vtkKWObject *already* have a pointer to a vtkKWApplication object, i.e. you are either duplicating it, or using two, and if not synced properly, bad things will happen :) In our case here, there is a probably with ref counting, etc., we have to clean that.

• Comments. Comments. Comments !
• Style. Style. Style !

• I found no less than 3 different instances of '#define SLICER_VTK5' and two of '#define VTKSLICER_STATIC'. This should probably be unified on top