If I press the right side button of the button group then the workflow steps are executed in order perfectly, but the widgets are not replaced neither after the individual steps nor at the end.

So at the end all the steps have been executed but I still see the page where I press the finish button.

The doxygen comment are written using two styles (java and triple slahes).

Since most of the comments are written using ///, I would suggest to update the few places where java style is used.

See:

• https://github.com/commontk/CTK/blob/master/Libs/DICOM/Core/ctkDICOMIndexer.h
• http://www.stack.nl/~dimitri/doxygen/commands.html

In some builds, we have the error: make: *** No rule to make target `CTKCorePlugins'. Stop.
http://my.cdash.org/viewBuildError.php?buildid=218950

It's normal as there is no CTKCorePlugins project.
I couldn't find where it is defined in the CMakeLists.txt/CMake macros...

Any idea ?
Here are the full logs:

Build CTKCore
...
----------- [ Build CTKCoreCppTests ] -----------
...
----------- [ Build CTKCorePlugins ] -----------
SetMakeCommand:/usr/bin/make -i -j8 "CTKCorePlugins"
SetCTestConfiguration:MakeCommand:/usr/bin/make -i -j8 "CTKCorePlugins"
SetCTestConfiguration:UseLaunchers:0
SetCTestConfiguration:BuildDirectory:/home/julien/work/nightly-builds/CTK-Superbuild-Release-nightly/CTK-build
SetCTestConfiguration:SourceDirectory:/home/julien/work/nightly-builds/CTK
Build project
MakeCommand:/usr/bin/make -i -j8 "CTKCorePlugins"
Run command: "/usr/bin/make" "-i" "-j8" "CTKCorePlugins"
Each symbol represents 1024 bytes of output.
'!' represents an error and '' a warning.
.make: ** No rule to make target `CTKCorePlugins'. Stop.
Size of output: 0K
Command exited with the value: 2
MakeCommand:/usr/bin/make -i -j8 "CTKCorePlugins"
Error(s) when building project
1 Compiler errors
1 Compiler warnings
SetCTestConfiguration:DropMethod:http
SetCTestConfiguration:DropSite:my.cdash.org
SetCTestConfiguration:DropLocation:/submit.php?project=CTK
SetCTestConfiguration:IsCDash:TRUE
Add file: /home/julien/work/DashboardScripts/ctkDashboardScript-Release-nightly.cmake
SetCTestConfiguration:BuildDirectory:/home/julien/work/nightly-builds/CTK-Superbuild-Release-nightly
SetCTestConfiguration:SourceDirectory:/home/julien/work/nightly-builds/CTK
Submit files (using http)
Using HTTP submit method
Drop site:http://my.cdash.org/submit.php?project=CTK
Upload file: /home/julien/work/nightly-builds/CTK-Superbuild-Release-nightly/Testing/20110810-0300/Build.xml to http://my.cdash.org/submit.php?project=CTK&FileName=eris.kitware___Linux-g%2B%2B4.3.3-QT4.6.3-Release___20110810-0300-Nightly___XML___Build.xml&MD5=11ca07e8ca5a8f1efbbc5bde21b150d9 Size: 1564
Uploaded: /home/julien/work/nightly-builds/CTK-Superbuild-Release-nightly/Testing/20110810-0300/Build.xml
Submission successful
Build CTKWidgets
...

Instead of specifying "origin/master", would it be possible to use a specific SHA1 as a GIT_TAG. Doing so will be more deterministic and ensure all developers / checkout will behave the same way. Before, origin/patched associated with our own DCMTK was a "controller" moving target.

The validator message does not appear in the widget. The validator sets it by the setStatusText, but it does not arrive to the error section of the groupbox.

Let's suppose that we are in Step 1 and the workflow widget displays Page 1, and every step has its own page.

If you press the Next button then you get to Page 2 after that the Step 1 send the onExitComplete signal. That is fine.

However, you will be in Step 2 immediately after you press the Next button. The transition should be done only after the onExitComplete signal.

On Linux the text ("Next") does not appear on the button. On Windows, it appears but it aligned to left, there is space between the the icon and the text. The icon appears in the middle in both platforms.

This is because there was an attempt to put the icon to the right side of the text (line 107), however it does not work.

I tried to set the alignment additionally by
this->NextButton->setStyleSheet("text-align: right");
but I could only reach that the text appeared also on Linux, but still on the left side of the button.

For consistency with CMake best practice. See http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_PATCH_VERSION

Checking test dependency graph end
test 31
    Start 31: ctkWorkflowTest2

31: Test command: /home/jchris/Projects/CTK-Superbuild-Debug/CTK-build/bin/CTKCoreCppTests "ctkWorkflowTest2"
31: Test timeout computed to be: 1500
31: QMetaObject::invokeMethod: No such method ctkWorkflowStepPrivate::validationComplete(bool)
1/1 Test #31: ctkWorkflowTest2 .................   Passed    0.58 sec

Thanks to Michael Jeulinl to indentify the issue and initiate the work

Microsoft visual studio doesn't support command lines longer than 8000 characters.
Write the arguments into a file instead of on the command line.
See discussion from Dean Inglis on Feb. 15th,16th 2011.

Dave partika wrote:

That command line is longer than 8000 characters which is all that Windows supports. To work around this Marcus and I added a new argument to ExternalProject called CMAKE_CACHE_ARGS (instead of CMAKE_ARGS). This will write out a cache file with all those arguments in it instead of passing them via the command line.

It is a new feature in CMake 2.8.4 (or you can just take ExternalProject.cmake from that repo and keep your own copy in CTK if you don't want to change your required cmake).

Here is an example.

ExternalProject_Add(png
URL ${PNG_URL}/${PNG_GZ}
URL_MD5 ${PNG_MD5}
UPDATE_COMMAND ""
SOURCE_DIR ${png_source}
BINARY_DIR ${png_binary}
INSTALL_DIR ${png_install}
CMAKE_CACHE_ARGS
-DCMAKE_CXX_FLAGS:STRING=${pv_tpl_cxx_flags}
-DCMAKE_C_FLAGS:STRING=${pv_tpl_c_flags}
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_CFG_INTDIR}
${pv_tpl_compiler_args}
-DZLIB_INCLUDE_DIR:STRING=${ZLIB_INCLUDE_DIR}
-DZLIB_LIBRARY:STRING=${ZLIB_LIBRARY}
CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
DEPENDS ${png_dependencies}
)

Looking at the code coverage of ctkWorkflowStep, it shows that there is memory leak in ctkWorkflowStep.

http://my.cdash.org/viewCoverageFile.php?buildid=216920&fileid=604284

Hi,

When I activate
CTK_PLUGIN_org.commontk.slicer ON

in ccmake interface, I got the following error after pressing 'c' to configure :

CMake Error at CMake/ctkMacroValidateBuildOptions.cmake:177 (MESSAGE):
org_commontk_slicermodule depends on CTKModuleDescription, which does not
exist
Call Stack (most recent call first):
CMakeLists.txt:521 (ctkMacroValidateBuildOptions)

Is there a known to correct this?

I am working under Fedora OS.
Regards,

Hi Folks,

1. Github provides a wiki - Should we use it ?

2. Should we add a pointer to this one: http://www.commontk.org/index.php/Main_Page ?

3. Who want to be organize the doc / bug people with some "stuff" need to be updated .. ? Do we need such a person ?

Jc

On my Ubuntu 11.04 machine, libCTKDICOMCore does not link due to missing zlib symbols.

Adding "z" to the link libraries of CTKDCIOMCore would solve this issue. Is this the way to go?

During the November CTK hackfest, consensus has been reached. It has been decided to remove the Log4Qt dependency.

See details below

/home/jchris/Projects/CTK/Libs/DICOM/Core/ctkDICOMRetrieve.cpp:240: warning: passing ‘Uint16’ chooses ‘int’ over ‘uint’ [-Wsign-promo]
/home/jchris/Projects/CTK/Libs/DICOM/Core/ctkDICOMRetrieve.cpp:240: warning:   in call to ‘static QString QString::number(int, int)’ [-Wsign-promo]
/home/jchris/Projects/CTK/Libs/DICOM/Core/ctkDICOMRetrieve.cpp:241: warning: passing ‘Uint16’ chooses ‘int’ over ‘uint’ [-Wsign-promo]
/home/jchris/Projects/CTK/Libs/DICOM/Core/ctkDICOMRetrieve.cpp:241: warning:   in call to ‘static QString QString::number(int, int)’ [-Wsign-promo]
/home/jchris/Projects/CTK/Libs/DICOM/Core/ctkDICOMRetrieve.cpp:242: warning: passing ‘Uint16’ chooses ‘int’ over ‘uint’ [-Wsign-promo]
/home/jchris/Projects/CTK/Libs/DICOM/Core/ctkDICOMRetrieve.cpp:242: warning:   in call to ‘static QString QString::number(int, int)’ [-Wsign-promo]

Hi,

Here is the error message:

[ 71%] Built target org_commontk_qtmobility_service
[ 71%] Generating moc_ctkEventBusImpl_p.cxx
/home2/code/CTK/Plugins/org.commontk.eventbus/ctkEventBusImpl_p.h:39: Error: Undefined interface
make[5]: *** [Plugins/org.commontk.eventbus/moc_ctkEventBusImpl_p.cxx] Error 1
make[4]: *** [Plugins/org.commontk.eventbus/CMakeFiles/org_commontk_eventbus.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [CMakeFiles/CTK-build] Error 2
make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2
make: *** [all] Error 2

Do you know what's wrong?

Regards

The ctkSliderWidget crashes here in debug mode with this message:

ASSERT: "d->equal(d->SpinBox->value(),d->Slider->value())" in file /home/espakm/src/CTK/Libs/Widgets/ctkSliderWidget.cpp, line 258

The code:

void ctkSliderWidget::setValue(double _value)
{
Q_D(ctkSliderWidget);
// disable the tracking temporally to emit the
// signal valueChanged if changeValue() is called
bool isChanging = d->Changing;
d->Changing = false;
d->SpinBox->setValue(_value);
// Why do we need to set the value to the slider ?
//d->Slider->setValue(d->SpinBox->value());
//double spinBoxValue = d->SpinBox->value();
Q_ASSERT(d->equal(d->SpinBox->minimum(),d->Slider->minimum()));
Q_ASSERT(d->equal(d->SpinBox->value(),d->Slider->value())); // line 258
Q_ASSERT(d->equal(d->SpinBox->maximum(),d->Slider->maximum()));
// restore the prop
d->Changing = isChanging;
}

I am afraid that the commented line (255) should be uncommented.

Sasha - July 7 2011 > http://www.cmake.org/pipermail/cmake/2011-July/045306.html

Jc - August 15 2011 > Did you get any answer regarding your question ?

Sasha - August 15 2011 >

No, I didn' get any. After some more discussions internally, we concluded that the behavior will always be confusing for somebody (overwriting or not).

The same is true for CTK, by the way. After a successful superbuild, if you enable some library or plug-in using the CTK-build/ build dir and then use the superbuild build dir to configure and build again, your previous changes will be overwritten. On the other hand, if we wouldn't overwrite the CTK_[APP|LIB|PLUGIN]_ variables, this would be confusing too...

I "solved" the issue for MITK by removing all CMake options from the superbuild which are meant to enable/disable certain parts of the project and use a default configuration during superbuild only. For CTK, we would need to find a way to read the actual cache value of the variable in the CTK-build dir if we are in superbuild mode.

It's a 32bit build on a 64bit windows. Maybe it's still a local configuration problem with Qt, but I think we could improve the error message. Maybe we could try first to run DGraph without parameters just to check if the general setup is ok.

4>CMake Error at CMake/ctkMacroValidateBuildOptions.cmake:137 (MESSAGE):
4>  Failed to obtain dependence path of CTKCore.
4>  Exit code 0xc0000135
4> 
4>  C:/HOME/Pahontu/MITK/32_bits_MITK_bin/MITK-superbuild/CTK-build
4>Call Stack (most recent call first):
4>  CMakeLists.txt:501 (ctkMacroValidateBuildOptions)

'''
/usr/bin/ld: error: /home/jchris/Projects/Slicer4-Superbuild-Debug/CTK-build/CMakeExternals/Install/lib/libofstd.a(oftime.o): requires unsupported dynamic reloc; recompile with -fPIC
collect2: ld returned 1 exit status
'''

Solution is to do something similar to what's done
line 104 in commontk/DCMTK@ef32e64#diff-7

Hi,

I got a compilation error under Fedora OS, while trying to build all the projects :

[ 0%] Performing build step for 'ITK'
[ 1%] Built target itksys
[ 6%] Built target itkjpeg8
[ 11%] Built target itkjpeg12
[ 16%] Built target itkjpeg16
[ 17%] Built target itkzlib
[ 18%] Built target itkpng
[ 18%] Built target itkmkg3states
[ 20%] Built target itktiff
[ 21%] Built target itkopenjpeg
[ 21%] Building CXX object Utilities/MetaIO/CMakeFiles/ITKMetaIO.dir/metaUtils.o
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx: In function ‘bool MET_StringToWordArray(const char_, int_, char_**)’:
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:800:3: error: ‘ptrdiff_t’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:800:3: note: suggested alternatives:
/usr/lib/gcc/i686-redhat-linux/4.6.1/../../../../include/c++/4.6.1/i686-redhat-linux/bits/c++config.h:156:15: note: ‘std::ptrdiff_t’
/usr/lib/gcc/i686-redhat-linux/4.6.1/../../../../include/c++/4.6.1/i686-redhat-linux/bits/c++config.h:156:15: note: ‘std::ptrdiff_t’
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:800:13: error: expected ‘;’ before ‘l’
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:802:13: error: expected ‘;’ before ‘p’
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:803:9: error: ‘p’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:803:11: error: ‘l’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:809:13: error: expected ‘;’ before ‘pp’
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:811:9: error: ‘pp’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:811:12: error: ‘l’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:824:3: error: ‘pp’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:824:6: error: ‘l’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:840:13: error: expected ‘;’ before ‘i’
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:841:7: error: ‘i’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:843:8: error: ‘p’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:849:11: error: ‘p’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:853:5: error: ‘j’ was not declared in this scope
/home2/code/CTK/CTK-superbuild/ITK/Utilities/MetaIO/metaUtils.cxx:854:11: error: ‘p’ was not declared in this scope
make[5]: *_* [Utilities/MetaIO/CMakeFiles/ITKMetaIO.dir/metaUtils.o] Error 1
make[4]: *** [Utilities/MetaIO/CMakeFiles/ITKMetaIO.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [ITK-cmake/src/ITK-stamp/ITK-build] Error 2
make[1]: *** [CMakeFiles/ITK.dir/all] Error 2
make: *** [all] Error 2

Any idea to solve it? Thanks in advance!

Regards

Hi to all,

would it be possible to have a ctkFileButton with similar functionality than the ctkDirectoryButton? There are a couple use cases where it makes sense to be able to select a file (even if it doesn't exist yet)

http://www.commontk.org/docs/html/classctkDirectoryButton.html

Thanks in advance
Demian

See http://public.kitware.com/Bug/view.php?id=12378

Doing a CTK superbuild using Make files does not propagate the -j option to the build step of the inner CTK project. The following topic branch would solve this issue:

https://github.com/saschazelzer/CTK/tree/fix-superbuild-parallel-make

Would that have any side effects I am not aware of?

Thanks,
Sascha

Would be great to transfer the wiki page realted to the plugin framework from the old wiki to the new one. Sasha ?

See http://wiki.github.com/pieper/CTK/ctk-plugin-framework

I just observed this on a fresh ubuntu install with missing QSQLITE driver which is not installed by default with libqt4-dev:

QSqlDatabase: QSQLITE driver not loaded
QSqlDatabase: available drivers: QMYSQL3 QMYSQL
terminate called after throwing an instance of 'ctkPluginDatabaseException'
what(): Invalid database connection: plugins
Aborted

I think we should check this and print a more readable error message.

Hi,

I get linking error on building CTKVisualizationVTKWidgetsPlugins within /ctkVTKThresholdWidgetTest1.cpp :

Built target CTKVisualizationVTKWidgetsPlugins
Linking CXX executable ../../../../../../bin/CTKVisualizationVTKWidgetsCppTests
CMakeFiles/CTKVisualizationVTKWidgetsCppTests.dir/ctkVTKThresholdWidgetTest1.cpp.o: In function ctkVTKThresholdWidgetTest1(int, char**)': /home2/code/CTK/Libs/Visualization/VTK/Widgets/Testing/Cpp/ctkVTKThresholdWidgetTest1.cpp:83: undefined reference toctkVTKScalarsToColorsView::ctkVTKScalarsToColorsView(QWidget_)'
/home2/code/CTK/Libs/Visualization/VTK/Widgets/Testing/Cpp/ctkVTKThresholdWidgetTest1.cpp:84: undefined reference to ctkVTKScalarsToColorsView::addOpacityFunction(vtkPiecewiseFunction_, bool)' /home2/code/CTK/Libs/Visualization/VTK/Widgets/Testing/Cpp/ctkVTKThresholdWidgetTest1.cpp:83: undefined reference to ctkVTKScalarsToColorsView::~ctkVTKScalarsToColorsView()'
/home2/code/CTK/Libs/Visualization/VTK/Widgets/Testing/Cpp/ctkVTKThresholdWidgetTest1.cpp:83: undefined reference to`ctkVTKScalarsToColorsView::~ctkVTKScalarsToColorsView()'
collect2: ld returned 1 exit status
make[5]: *** [bin/CTKVisualizationVTKWidgetsCppTests] Error 1
make[4]: *** [Libs/Visualization/VTK/Widgets/Testing/Cpp/CMakeFiles/CTKVisualizationVTKWidgetsCppTests.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [CMakeFiles/CTK-build] Error 2
make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2
make: *** [all] Error 2

Regards

Recently I was trying to develop a program to transfer the dicom images. Through the ctkDicomDemoSCU, I found that the dcmscp and dcmscu classes may be fit for this job. So I tried to do several experiments with dcmscp. First, I created a server using the dcmscp and listen to the scu. With the help of ctkDicomDemoSCU, I connected to the scp server successfully. But when I tried to transfer dicom images, the scp server received nothing. Then I checked the code and found that the dcmscp only handles the DIMSE_C_ECHO_RQ command.
I want to know that if the dcmscp class will be finished with the function receiving dicom images. Thanks!

With slicer dashboards, we have frequent (>2x a week?) dashboards that fail the step of downloading dcmtk.
I suspect that part of the reason is because the download uses the http protocol.
Would it be possible for the offis team to add the git protocol as a way to access the dcmtk repo?
If it is not feasible, then I guess we can clone the official repo on github/commontk and use that one instead, hopefully it will solve our download failure.

From Arnaud Gelas:

Hi,

I globally set up my git to convert line endings. I have local modifications in one file cause it uses CRLF.

Could we agree on setting LF as line ending for the project?
If that's ok, I can commit and push my local changes...

Note: you may find this interesting http://help.github.com/dealing-with-lineendings/
$ git config --global core.autocrlf input

Arnaud

Hi !
I am currently working on a project using CommonTK. I need to manage the entire compilation process including CTK compilation. So, for several reasons, I have to disable the git clone of all CTK dependencies. I want to clone these dependencies only one time (at the first compilation) and disable it for the next compilation.

How can I do this ?

Kind regards, Brice

Add package target so that the following is supported:
make package

Arch/platform: 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

sha1: b483166

Details of the error:

Linking CXX shared library ../../bin/plugins/liborg_commontk_qtmobility_service.dylib
Undefined symbols:
"QtMobility::QServiceManager::addService(QIODevice_)", referenced from:
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceManager::QServiceManager(QObject_)", referenced from:
ctkQtMobilityServiceRuntime::ctkQtMobilityServiceRuntime(ctkPluginContext_)in ctkQtMobilityServiceRuntime.cpp.o
ctkQtMobilityServiceRuntime::ctkQtMobilityServiceRuntime(ctkPluginContext_)in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceManager::findInterfaces(QString const&) const", referenced from:
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceInterfaceDescriptor::~QServiceInterfaceDescriptor()", referenced from:
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
QListQtMobility::QServiceInterfaceDescriptor::node_copy(QListQtMobility::QServiceInterfaceDescriptor::Node_, QListQtMobility::QServiceInterfaceDescriptor::Node_, QListQtMobility::QServiceInterfaceDescriptor::Node_)in ctkQtMobilityServiceRuntime.cpp.o
QListQtMobility::QServiceInterfaceDescriptor::node_destruct(QListQtMobility::QServiceInterfaceDescriptor::Node_, QListQtMobility::QServiceInterfaceDescriptor::Node_)in ctkQtMobilityServiceRuntime.cpp.o
ctkQtMobilityServiceFactory::~ctkQtMobilityServiceFactory()in moc_ctkQtMobilityServiceFactory_p.cxx.o
ctkQtMobilityServiceFactory::~ctkQtMobilityServiceFactory()in moc_ctkQtMobilityServiceFactory_p.cxx.o
ctkQtMobilityServiceFactory::~ctkQtMobilityServiceFactory()in moc_ctkQtMobilityServiceFactory_p.cxx.o
ctkQtMobilityServiceFactory::~ctkQtMobilityServiceFactory()in moc_ctkQtMobilityServiceFactory_p.cxx.o
"QtMobility::QServiceInterfaceDescriptor::minorVersion() const", referenced from:
ctkQtMobilityServiceFactory::ungetService(QSharedPointer, ctkServiceRegistration, QObject_) in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceFactory::getService(QSharedPointer, ctkServiceRegistration) in ctkQtMobilityServiceFactory.cpp.o
"QtMobility::QServiceInterfaceDescriptor::serviceName() const", referenced from:
ctkQtMobilityServiceFactory::ungetService(QSharedPointer, ctkServiceRegistration, QObject_) in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceFactory::getService(QSharedPointer, ctkServiceRegistration) in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceManager::loadInterface(QtMobility::QServiceInterfaceDescriptor const&, QtMobility::QServiceContext_, QtMobility::QAbstractSecuritySession_)", referenced from:
ctkQtMobilityServiceFactory::getService(QSharedPointer, ctkServiceRegistration) in ctkQtMobilityServiceFactory.cpp.o
"QtMobility::QServiceInterfaceDescriptor::majorVersion() const", referenced from:
ctkQtMobilityServiceFactory::ungetService(QSharedPointer, ctkServiceRegistration, QObject_) in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceFactory::getService(QSharedPointer, ctkServiceRegistration) in ctkQtMobilityServiceFactory.cpp.o
"QtMobility::QServiceManager::error() const", referenced from:
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceManager::~QServiceManager()", referenced from:
ctkQtMobilityServiceRuntime::~ctkQtMobilityServiceRuntime()in moc_ctkQtMobilityServiceRuntime_p.cxx.o
ctkQtMobilityServiceRuntime::~ctkQtMobilityServiceRuntime()in moc_ctkQtMobilityServiceRuntime_p.cxx.o
ctkQtMobilityServiceRuntime::~ctkQtMobilityServiceRuntime()in moc_ctkQtMobilityServiceRuntime_p.cxx.o
ctkQtMobilityServiceRuntime::~ctkQtMobilityServiceRuntime()in moc_ctkQtMobilityServiceRuntime_p.cxx.o
"QtMobility::QServiceInterfaceDescriptor::QServiceInterfaceDescriptor(QtMobility::QServiceInterfaceDescriptor const&)", referenced from:
ctkQtMobilityServiceFactory::ctkQtMobilityServiceFactory(QtMobility::QServiceInterfaceDescriptor const&, ctkQtMobilityServiceRuntime_, QSharedPointer)in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceFactory::ctkQtMobilityServiceFactory(QtMobility::QServiceInterfaceDescriptor const&, ctkQtMobilityServiceRuntime_, QSharedPointer)in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
QListQtMobility::QServiceInterfaceDescriptor::node_copy(QListQtMobility::QServiceInterfaceDescriptor::Node_, QListQtMobility::QServiceInterfaceDescriptor::Node_, QListQtMobility::QServiceInterfaceDescriptor::Node_)in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceInterfaceDescriptor::customAttribute(QString const&) const", referenced from:
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceInterfaceDescriptor::customAttributes() const", referenced from:
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
"QtMobility::QServiceInterfaceDescriptor::interfaceName() const", referenced from:
ctkQtMobilityServiceFactory::ungetService(QSharedPointer, ctkServiceRegistration, QObject_) in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceFactory::getService(QSharedPointer, ctkServiceRegistration) in ctkQtMobilityServiceFactory.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
ctkQtMobilityServiceRuntime::processPlugin(QSharedPointer) in ctkQtMobilityServiceRuntime.cpp.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [bin/plugins/liborg_commontk_qtmobility_service.dylib] Error 1
make[1]: *** [Plugins/org.commontk.qtmobility.service/CMakeFiles/org_commontk_qtmobility_service.dir/all] Error 2
make: *** [all] Error 2

• The network connection in ctkDICOMRetrieve is never "dropped". Consequent calls to the retrieve function ends up with the message that "The network address is already in use" as the association is never closed.
  Should include call to closeAssociation on several places. It would be even better to use the member SCU (narked as to-do) in the source, to make it even better. Special care should be taken on exception when called from "outside".
• Retrieved object are written to the disk two times. The portion of code "borrowed" from the dcmdjpeg example should not exist in the retrieve code, because the data (according to the design) should be and is written in the database.insert().
• Also, in ctkDICOMDatabase, there is a problem with retrieved object paths/filenames. The present system of using UIDs is not compliant with the DICOM standard, especially if you would like to create (proper) DICOMDIR and archive media. Paths and filenames should be generated to have max 8 characters according to the DICOM standard (check with Clunie if you don't beleive me :) )
• Different behavior of in-memory and file database should not be implemented (at least not like that) in the Core library code. One should expect that the call to a function (insert()) should depend on parameters only.
• You should also correct the calls to database.insert() to reflect the needed use.
  For instance, in ctkDICOMQuery, the call to database.insert() is missing "false, false" (causing some side-efects, like trying to generate thumbnails for non-existent images)

Enough for this post :)
Keep the good work,
Dragan Toroman

http://my.cdash.org/viewBuildError.php?buildid=214707

For some reasons, Log4Qt refuses to get compiled by the Superbuild with Visual Studio 2010 (Log4t source dir is correctly downloaded, however, Log4Qt-build is empty).
However, it compiles fine when running cmake on the project manually.

Any idea ?

Thanks,
Julien.

Build started 7/31/2011 5:27:36 PM.
     1>Project "C:\work\CTK\Dashboards\CTK-Superbuild-Release-experimental\Log4Qt.vcxproj" on node 2 (build target(s)).
     1>InitializeBuildStatus:
         Creating "x64\Release\Log4Qt\Log4Qt.unsuccessfulbuild" because "AlwaysCreate" was specified.
       ComputeCustomBuildOutput:
         Creating directory "C:\work\CTK\Dashboards\CTK-Superbuild-Release-experimental\Log4Qt-cmake\src\Log4Qt-stamp\Release\".
       CustomBuild:
         Creating directories for 'Log4Qt'
         Performing download step (git clone) for 'Log4Qt'
         Cloning into Log4Qt...
         Note: checking out 'origin/patched'.

         You are in 'detached HEAD' state. You can look around, make experimental
         changes and commit them, and you can discard any commits you make in this
         state without impacting any branches by performing another checkout.

         If you want to create a new branch to retain commits you create, you may
         do so (now or later) by using -b with the checkout command again. Example:

           git checkout -b new_branch_name

         HEAD is now at 8d3558b... Do not export Target
         Performing update step (git fetch) for 'Log4Qt'
       FinalizeBuildStatus:
         Deleting file "x64\Release\Log4Qt\Log4Qt.unsuccessfulbuild".
         Touching "x64\Release\Log4Qt\Log4Qt.lastbuildstate".
     1>Done Building Project "C:\work\CTK\Dashboards\CTK-Superbuild-Release-experimental\Log4Qt.vcxproj" (build target(s)).
Build succeeded.
Time Elapsed 00:00:04.30

Tests failing:
ctkCommandLineParserTest1, ctkErrorLogModelTest1 and ctkErrorLogModelTest3

Hi,

I've tried to build CTK on my mac running Mac OS X 10.5 and the build fail with this error:

[ 46%] Building CXX object CMakeFiles/PythonQt.dir/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns_init.cpp.o
/Users/glehmann/src/CTK/build/CMakeExternals/Source/PythonQt/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns0.h: In member function ‘QAbstractXmlReceiver* PythonQtWrapper_QAbstractXmlReceiver::new_QAbstractXmlReceiver(const QAbstractXmlReceiver&)’:
/Library/Frameworks/QtXmlPatterns.framework/Headers/qabstractxmlreceiver.h:100: error: ‘QAbstractXmlReceiver& QAbstractXmlReceiver::operator=(const QAbstractXmlReceiver&)’ is private
/Users/glehmann/src/CTK/build/CMakeExternals/Source/PythonQt/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns0.h:157: error: within this context
make[5]: *** [CMakeFiles/PythonQt.dir/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns0.cpp.o] Error 1
make[5]: *** Waiting for unfinished jobs....
/Users/glehmann/src/CTK/build/CMakeExternals/Source/PythonQt/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns0.h: In member function ‘QAbstractXmlReceiver* PythonQtWrapper_QAbstractXmlReceiver::new_QAbstractXmlReceiver(const QAbstractXmlReceiver&)’:
/Library/Frameworks/QtXmlPatterns.framework/Headers/qabstractxmlreceiver.h:100: error: ‘QAbstractXmlReceiver& QAbstractXmlReceiver::operator=(const QAbstractXmlReceiver&)’ is private
/Users/glehmann/src/CTK/build/CMakeExternals/Source/PythonQt/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns0.h:157: error: within this context
make[5]: *** [CMakeFiles/PythonQt.dir/generated_cpp/com_trolltech_qt_xmlpatterns/com_trolltech_qt_xmlpatterns_init.cpp.o] Error 1
make[4]: *** [CMakeFiles/PythonQt.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [CMakeExternals/Stamp/PythonQt/PythonQt-install] Error 2
make[1]: *** [CMakeFiles/PythonQt.dir/all] Error 2
make: *** [all] Error 2

Any idea of what is wrong?

Regards,

Gaëtan

CTK relies on the "official" FindGit.cmake script, which gives precedence to "git.cmd" when looking for a git executable.

On Windows, using git.cmd instead of git.exe leads to problems when used in the default git update command of the ExternalProject_Add macro. The default update command should execute several git calls (fetch, checkout, submodule update) where only the first is actually run. Using git.exe, all calls are executed correctly.

We should roll our own version of FindGit.cmake, giving priority to git.exe on Windows. This should probably also be fixed in the CMake version of the script.

See example below - touch a file in a widget lib, type make at toplevel: nothing is rebuilt. Run make inside subdirectory and rebuild is done.

This same issue is causing build errors for sicer4 so people are needing to rebuild their CTK manually.

-Steve

pieper@boggs:/ctk/latest/CTK-superbuild$ make
[ 14%] Built target DCMTK
[ 28%] Built target PythonQt
[ 42%] Built target Log4Qt
[ 57%] Built target CTKData
[ 71%] Built target VTK
[ 85%] Built target CTK-Configure
[100%] Built target CTK-build
pieper@boggs:/ctk/latest/CTK-superbuild$ touch ../CTK/Libs/DICOM/Widgets/ctkDICOMAppWidget.cpp
pieper@boggs:/ctk/latest/CTK-superbuild$ make
[ 14%] Built target DCMTK
[ 28%] Built target PythonQt
[ 42%] Built target Log4Qt
[ 57%] Built target CTKData
[ 71%] Built target VTK
[ 85%] Built target CTK-Configure
[100%] Built target CTK-build
pieper@boggs:/ctk/latest/CTK-superbuild$ (cd CTK-build; make)
[ 5%] Built target CTKCore
[ 5%] Built target CTKDummyPlugin
[ 8%] Built target CTKCoreCppTests
[ 15%] Built target CTKPluginFramework
[ 15%] Built target CTKPluginFrameworkTestUtil
[ 15%] Built target pluginSL1_test
[ 16%] Built target pluginSL4_test
[ 17%] Built target pluginA2_test
[ 18%] Built target pluginA_test
[ 18%] Built target pluginD_test
[ 19%] Built target pluginSL3_test
[ 20%] Built target org_commontk_pluginfwtest
[ 20%] Built target CTKPluginFrameworkCppTests
[ 22%] Built target org_commontk_configadmintest
[ 25%] Built target org_commontk_eventadmintest
[ 26%] Built target pluginAttrPwd_test
[ 27%] Built target org_commontk_metatypetest
[ 52%] Built target CTKWidgets
[ 63%] Built target CTKWidgetsPlugins
[ 72%] Built target CTKWidgetsCppTests
[ 75%] Built target CTKDICOMCore
[ 77%] Built target CTKDICOMCoreCppTests
Scanning dependencies of target CTKDICOMWidgets
[ 77%] Building CXX object Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMAppWidget.cpp.o
Linking CXX shared library ../../../bin/libCTKDICOMWidgets.so
[ 81%] Built target CTKDICOMWidgets
Linking CXX executable ../../../../../bin/CTKDICOMWidgetsCppTests
[ 82%] Built target CTKDICOMWidgetsCppTests
[ 82%] Built target CTKScriptingPythonCore
[ 82%] Built target CompileCTKScriptingPythonCorePythonFiles
[ 82%] Built target CTKScriptingPythonCoreCppTests
[ 83%] Built target CTKScriptingPythonWidgets
[ 84%] Built target CTKScriptingPythonWidgetsPlugins
[ 84%] Built target CTKScriptingPythonWidgetsCppTests
[ 87%] Built target CTKVisualizationVTKCore
[ 88%] Built target CTKVisualizationVTKCoreCppTests
[ 94%] Built target CTKVisualizationVTKWidgets
[ 97%] Built target CTKVisualizationVTKWidgetsPlugins
[100%] Built target CTKVisualizationVTKWidgetsCppTests
Linking CXX executable ../../bin/ctkDICOM
[100%] Built target ctkDICOM
[100%] Built target ctkDICOMIndexer
[100%] Built target ctkDICOMDemoSCU
[100%] Built target ctkDICOMQuery
[100%] Built target ctkDICOMRetrieve
Linking CXX executable ../../bin/ctkDICOMQueryRetrieve
[100%] Built target ctkDICOMQueryRetrieve
Linking CXX executable ../../bin/ctkDICOMObjectViewer
[100%] Built target ctkDICOMObjectViewer
[100%] Built target CTKApplicationCppTests
pieper@boggs:~/ctk/latest/CTK-superbuild$

See http://www.commontk.org/index.php/Contributing_to_CTK

Click edit and you will see the work in progress commented using

If a ctkWorkflow is created, associated ctkWorkflowStep won't be automatically removed.
Thanks to Michael Jeulinl to indentify the issue and initiate the work

The checkbox in the ctkCheckablePushButton can be turned on by the setCheckable function instead of the setChecked function.

I wanted to make the button not checkable to disable switching the state interactively, but to switch the states from the program by setChecked. However, the functions did not do what I supposed.

From Jean-Christophe Fillion-Robin:

Sasha ? Do you think you could take care of that ? See details below:
/home/jchris/Projects/CTK/Libs/PluginFramework/EventBus/ctkEvent.cpp: In member function ‘const QVariant& ctkEvent::property(const QString&) const’:

/home/jchris/Projects/CTK/Libs/PluginFramework/EventBus/ctkEvent.cpp:57: warning: returning reference to temporary

thks
Jc

From Julien Finet:

When compiling, I got the following errors:

In file included from /home/julien/work/git/CTK/Utilities/ZMQ/uuid.cpp:21:
/home/julien/work/git/CTK/Utilities/ZMQ/uuid.hpp:67: error: ‘uuid_t’ in namespace ‘::’ does not name a type /home/julien/work/git/CTK/Utilities/ZMQ/uuid.cpp: In constructor ‘zmq::uuid_t::uuid_t()’: /home/julien/work/git/CTK/Utilities/ZMQ/uuid.cpp:80: error: ‘uuid’ was not declared in this scope /home/julien/work/git/CTK/Utilities/ZMQ/uuid.cpp:80: error: ‘uuid_generate’ was not declared in this scope /home/julien/work/git/CTK/Utilities/ZMQ/uuid.cpp:81: error: ‘uuid_unparse’ was not declared in this scope

The uuid-devel package was missing, it needed to be installed. How about checking if the uuid.h file exists at configuration time instead of compile time ?

Wouldn't it be better if the driver script automatically downloaded is found on github instead of http://commontk.org/ctkDashboardDriverScript.cmake?
I'm thinking of https://raw.github.com/commontk/CTK/master/CMake/ctkDashboardDriverScript.cmake or gists and suchs
That way we wouldn't have to rely on our sysadmin to update http://commontk.org/ctkDashboardDriverScript.cmake

From Luis Ibanez:

There is no Nightly Dynamic Analysis build reporting to the Dashboard.

1. in CTK/Libs/DICOM/Core/ctkDICOMDatabase.cpp
   the tag DCM_ModalitiesInStudy is not read correctly
   Instead of:
   dataset->findAndGetOFString(DCM_ModalitiesInStudy, modalitiesInStudy);
   it should be:
   dataset->findAndGetOFStringArray(DCM_ModalitiesInStudy, modalitiesInStudy);
   to allow reading multiple modalities (XX\YY\ZZ)
2. Also, you might consider more "standard" way of performing the query with the modalities filter. Although the fact that many SCP implement search by the ModalitiesInStudy tag, it is not according to the DICOM standard and is rather a IHE extension with undefined behavior when used as a search criterion (well, it works well with dcm4chee). So it might now work with all DICOM compliant SCPs. The "proper" way (according to DICOM specifications) would be to perform a query for all needed modalities and combine the results.
3. Rather more important issue is that the current database design lacks a VERY important thing. In DICOM, modalities are part of Series, not the Study, and the ModalitiesInStudy is "informative" and new feature that you should use on Study level for information on the Study, but in your current implementation, you don't have the information on the actual modality of every series. This is a very important information and it is missing although it exists in the dataset. So at present with (1) not fixed you get for study with 2 modalities (XA\OT)

STUDY (XA)

• SERIES 1
• SERIES 2

instead of

STUDY (XA\OT) -----> *with (1) fixed

• SERIES 1 (XA)
• SERIES 2 (OT)

Regards
Dragan Toroman

pseudocode for workflow steps creation from python:

• create step 1 (with no name/description)
• create step 2 (with no name/description)
• create workflow widget and add steps
• display workflow widget
• set name/description for steps 1 and 2
• expected to see workflow update, and it didn't

Problem: missing some signals on ctkWorkflowStep such as NameChanged(QString) and DescriptionChanged(QString) that the ctkWorkflowGroupBox should be listening to

Note: setting the name/description before adding the step to the workflow works as expected.

Hi,

Feature Request: Please create an install target.

The following standard cmake workflow doesn't work right now.
cmake .
make
make install

Thanks
Dominique