BUG: Fix ApplyAndWait Completed CLI node status

By not observing the application logic, the cli logic was never notified
when the CLI node was completed and could not set the status accordingly.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21956 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: 3072. Observe TransformModifiedEvent in the vtkMRMLTransformableNode.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21957 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: add more keyboard shortcuts in Editor

Per request from Sonia, give shortcuts for paint, draw, wand, and
rectangle effects.

See full list here:

http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/Editor#Editor_Wide_Keystrokes

Also STYLE: some dead code removal and end-of-line space removal.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21958 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: 3094. Update ROI selection widget after an ROI is selected


git-svn-id: http://svn.slicer.org/Slicer4/trunk@21959 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Remove python patch step related to "dll boundaries" hack

As explained in r21863, patching pythonrun.h and pythonrun.c was
required to prevent crash (related to dll boundaries [1][2]) when
building Slicer debug against a released python.

[1] http://stackoverflow.com/questions/2322095/why-does-this-program-crash-passing-of-stdstring-between-dlls
[2] http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/57e0d522-a42c-4add-963d-c87c6e76f161

Applying the approach discussed on the Blender mailing list[3], the
hack is not required anymore. This is made possible by using
"PyRun_String" function combined with the "execfile" statement.

[3] http://lists.blender.org/pipermail/bf-python/2008-May/005253.html

When transitioning to Python3 [4], use of "exec" and "compile" could be
considered:

  with open('foo.py', 'r') as fh:
    code = compile(fh.read(), 'foo.py', 'exec'); exec(code);

[4] http://stackoverflow.com/questions/436198/what-is-an-alternative-to-execfile-in-python-3-0

Approach making use of the "imp"  module could also be investigated [5][6]

[5] http://www.ragestorm.net/blogs/?tag=execfile
[6] http://docs.python.org/2/library/imp.html

Finally, let's note that overall approach to load module could be
revised to prevent side effect as the one described in
"qSlicerScriptedFileDialog::setPythonSource"

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21960 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Remove unused files

Follow up of previous commit r21960

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21961 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Prevent confusion removing unused "weave" external project

It was initially been introduced in r14346

The files have also been added to the Slicer attic for future reference.
See https://github.com/Slicer/Attic

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21962 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Use internally consistent zlib

The zlib libraries are used by many differnt packages
includeing ITKv4, LibArchive, VTK, python, and teem.

This patchset builds a single version of zlib
that is mangled with a slicer namespace, and uses
that one library for all zlib operation through the
"USE_SYSTEM_ZLIB" options.

The mangling for vtk_zlib is disabled for teem because
it is not needed when using the External_zlib build.

From: Hans Johnson <hans-johnson@uiowa.edu>

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21963 3bd1e089-480b-0410-8dfb-8563597acbee
STYLE: Remove obsolete comment from External_python.cmake

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21964 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: On MacOSX, do not create duplicate of MRMLIDIOPlugin and MGHIOPlugin

This fix MacOSX warning "/path/to/plugin is already loaded"

Both MRMLIDIOPlugin and MGHIOPlugin were copied so that it exists both
a "dylib" and a "so" version of the file. This was initially committed
on the 2007-09-27 to work around a limitation of ITK preventing it from
loading plugin having ".dylib" extension. See Slicer3 r4454 [1]

Then 2 months later, on the 2007-11-19, a fix has been pushed in ITK so
that plugin having extension "dylib" are considered. See ITK commit 28b4a6ba [2]

This commit account for the ITK fix by removing the code in charge of
copying the plugin.

Lessons learned: When implementing a hack, it is a good practice to report
a bug upstream to track the limitation and also reference the bug in a
comment starting with either "# HACK" for CMake file or "// HACK" for
c/cpp files. It would give a hint to developer re-factoring the code.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer3?view=revision&revision=4454
[2] https://github.com/Kitware/ITK/commit/28b4a6ba
ENH: Move MacOSX configuration code for CLI factory to a better place.

As a slight improvement, the path is also appended only if it exists.
ENH: Simplify logic by appending path to CLI factory only if they exist.
STYLE: Do not check for version of CMake before including "BundleUtilities"

Since minimum required CMake version for Slicer is 2.8.9, this message
is not needed anymore.
COMP: Ensure Python library directory is considered when fixing up package

When the expression "@SLICER_PYTHON_LIB_DIR@" has been introduced
in commit r21252 [1], it was already resolving to an empty
string because since r15463 [2] the file SlicerBlockCTKAppLauncherSettings is
included in the Applications/SlicerApp/CMakeLists.txt.

Both the fixup script and the launcher settings have been updated to
use the variable "PYTHON_LIBRARY_PATH" introduced in the top-level
CMakeLists.txt by commit r16822 [3]

To prevent such error from happening again, a convenient macro named
"_fixup_paths_append" has been introduced. It basically check if the path
passed as parameter exists and append it to the list of paths. If not,
it throw an error.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21252
[2] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=15463
[3] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=16822
COMP: Ensure library paths used for BundleFixup are valid

The helper macro "_fixup_paths_append" is now used consistently to append
path to the "libs_path" variable.

Let's also note the following updates:

 - CMAKE_RUNTIME_OUTPUT_DIRECTORY is not used anymore, instead
${Slicer_BUILD_DIR}/@Slicer_BIN_DIR@ is used.

 - Path "@Slicer_BINARY_DIR@/@Slicer_QtPlugins_DIR@" is not considered
anymore since it didn't exist in the build tree. Instead, the plugin path
are composed using "${Slicer_BUILD_DIR}/@Slicer_BIN_DIR@"
COMP: Do not explicitly fixup CLI shared libraries

Considering that (1) CLI shared lirbary are dependency
of CLI executable and (2) CLI executable are already discovered by the
fixup mechanism. There are no need to use candidate pattern for CLI
shared library.
COMP: Simplify expression used in gp_item_default_embedded_path_override.
STYLE: Easier configuration of fixup path in bundle script
BUG: Ensure library can be loaded from different place using @rpath

Before this commit, attempt have been made (r18311, r18325, r18581) to
install both built-in CLI and extension CLI executable in a folder
located at some depth of the main Slicer executable. This was needed
because all libraries were referenced based on the location of the main
Slicer executable using "@executable_path". This was working *only* in the
case of built-in CLI but wasn't scaling very well for the extension CLI
executable. Indeed, being able to both differentiate the different
installed extension and keeping the depth to 1 level wasn't easily
feasible:

  /path/to/Slicer.app/Contents/MacOS/Slicer
  /path/to/Slicer.app/Contents/cli-modules/MyCLI
  /path/to/Slicer.app/Contents/Extensions-21855/SkullStripper/cli-modules/MyCLI

A solution could have been to install extensions directly in "Slicer.app"
folder and update the cli install sub dir to get something like:

  /path/to/Slicer.app/Extensions-21855/SkullStripper/MyCLI

While possible, it would have remain a special case to maintain.

Instead, by using "@rpath", CLI modules can now be installed in the Slicer
standard location "Slicer_CLIMODULES_LIB_DIR" instead of "Slicer_CLIMODULES_SUBDIR".
This commit remove the special case which never worked (issue #3051)

Waiting the topic "tweak-bundleutilities-for-rpath" is fully matured and
integrated in CMake, use custom version of BundleUtilities and GetPrerequisites.
See http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/tweak-bundleutilities-for-rpath

Since our custom version of the CMake modules now consider "~/usr/.*/lib",
the implementation of "gp_resolved_file_type_override" has been removed.

Remove the hack specific to LibArchive (introduced by commit r19615), since
the library is fixed up using the default library matching pattern, it
will be installed in the expected location.

SlicerExecutionModel has also been updated to skip the installation of
CLI shared library and link the CLI executable with "-rpath" so that it
CLI executable can resolve the location of Slicer libraries.
COMP: Do not include "SlicerBlockSetCMakeOSXVariables" before project()

WORK IN PROGRESS ...


From Jc:

Hi Brad,


To summarize, the user build a building using a line similar to:

  cmake -DSlicer_DIR:PATH=/path/to/Slicer-build -DCMAKE_BUILD_TYPE:STRING=Release ../MyPlugin

  Passing Slicer_DIR is the only requirement.

// ------------------
You are right the file in source/build tree won't help.

// ------------------
Currently, the value for CMAKE_OSX_* are set in SlicerConfig.cmake and I would like the plugin to use these. The current approach is to force the following convention:

    set(EXTENSION_NAME "Foo")

    find_package(Slicer)
    include(${Slicer_USE_FILE})

    [...]

where project() was called within the Slicer use file.


// ------------------
By using this new approach:

   find_package(Slicer COMPONENTS ConfigurationPrerequisites)

   project(Foo)

   find_package(A ..)
   find_package(B ..)

  Can I be sure that the first call to "find_package" will be done before language feature are enabled ?



Thanks
Jc

// --------------------------
From Brad:

On 04/19/2013 10:54 AM, Jean-Christophe Fillion-Robin wrote:
>   cmake -DSlicer_DIR:PATH=/path/to/Slicer-build -DCMAKE_BUILD_TYPE:STRING=Release ../MyPlugin

Great, so find_package doesn't actually need to search but only
load the package config file.

> Currently, the value for CMAKE_OSX_* are set in SlicerConfig.cmake
> and I would like the plugin to use these. The current approach is
> to force the following convention:
>
>     set(EXTENSION_NAME "Foo")
>     find_package(Slicer)
>     include(${Slicer_USE_FILE})
>
> where project() was called within the Slicer use file.

Instead of the above three lines, try these three::

 project(Foo NONE)
 find_package(Slicer)
 SlicerConfigPlugin()

SlicerConfig.cmake provides the SlicerConfigPlugin macro to:

* FATAL_ERROR if languages are already enabled and tell the
  plugin author to add NONE to the project command

* Get the extension name from PROJECT_NAME, or alternatively
  from an optional explicit argument

* Set OS X platform variables and call enable_language()

Larger projects that provide a Slicer plugin along with a bunch
of other unrelated stuff will not want Slicer to control their
enable_language calls.  Therefore SlicerConfig should add another
macro (or options to this one) to just check that an already
enabled language has a matching platform selection and skip its
enable_language calls.

>    find_package(Slicer COMPONENTS ConfigurationPrerequisites)
>    project(Foo)
>    find_package(A ..)
>    find_package(B ..)
>
>   Can I be sure that the first call to "find_package" will be
>   done before language feature are enabled ?

Yes, but the above method may be even simpler.