Hi Sascha,

(In reply to comment #4)

Hi Sascha, sorry for the late reply.

OK, I reverted our changes back to be in-line with MITK master, and the installation process works for Linux and Mac, and if I recall correctly that was what the changes were for.

Hi there,

Hi Sascha,

Yes, we have a work around.
Thanks as always!

Error message

So I removed this:

We made a few, badly edited merges, changes, tweaks etc.

Adding an argument to FunctionCreateBlueBerryApplication for passing additional library search dirs (passing them through to the MITK_INSTALL_TARGETS macro) sounds like a useful addition to me. Do you mind adding a feature request in Bugzilla? Patches would be appreciated :-)

New remote branch pushed: bug-13706-add-library-dirs-to-create-application-macro

https://github.com/NifTK/MITK/commit/5fd6efd409fb027c74931c92a76e59e07d6bda93

Discussion with Sascha to address the second point only leads to:

Original Email reads thus:

In the piece of code here:
https://github.com/MITK/MITK/blob/master/CMake/mitkMacroInstall.cmake#L56

Checked in here:

Yes thats probably tidier. Sorry I cant look at it today.
M

Its because on Mac, the shared library suffix is .dylib and the shared module suffix is .so.

The CTK designer plugins are not processed by fixup_bundle. This means they are installed in the bundle using the stuff added in mitkInstallRules.cmake, but as there is no compile-time dependency, the fixup_bundle succeeds, and yet the libCTKWidgetsPlugins.so cannot be loaded due to having reference to libraries such as Qt, but from the original build tree, not the Qt libraries within the bundle.

Hi Marco,

Checked in:

For example, if someone running a project using MITK Project Template wants to turn on the CLI module, and use it in a deployed application after having run make package, or make install, the designer plugin needs to be there.

(In reply to comment #3)

Yes.

Does it currently work in your branch when running the application from the
build tree?

Hi Sascha,

(In reply to comment #114)

Hi Matt,

thanks for your contribution. The merged branch also updates CTK to the
latest version.

I will close this bug and new features or bug reports should get a new one.

CTK stuff merged to master

Hi Sascha,

Hi Sascha,

I win ... comment 100?

Hi Sascha,

Please note, URL of repository has changed.

Hi there,

And another last question. When doing a script to run BET, I came across the issue that some programs require specific ordering in their arguments.

Hi there,

Hi Sascha,

Hi Sascha,

Hi Sascha, please can you review the following:

(In reply to comment #83)

(In reply to comment #81)
Okay, but I think this would over-write the enabled state of "simple return
parameters" (such as an "int" parameter on the output channel). These
parameters are disabled by default when the gui is generated, because they
are just "labels" when the module reports some values for them (via xml).
They are shown in the gui to allow the values being displayed and updated,
but should never by editable. So when calling the new method with
enabled=true, these widgets will also be enabled.

So I think we have three choices:

a) Disable the complete generated GUI. Will very likely also disable the
expand/collapse buttons of the group widgets. This will preserve the enabled
state of child widgets.

b) In the XSL, create an extra child widget for each group box, containing
all parameter widgets and call disable on this new widget. This will also
preserve the enabled state of the parameter widgets.

c) In the new setParametersEnabled(bool) methods, remember the old enabled
state of all parameters.

(In reply to comment #82)

(In reply to comment #77)

I thought we could over-write the class name in the default XSL by using

ctkCmdLineModuleXslTransform::bindVariable("imageInputWidget",
"QmitkDataStorageComboBox")

and

ctkCmdLineModuleXslTransform::bindVariable("imageValueProperty",
"currentValue")

and then in the QUiLoader sub-class instantiate the QmitkDataStorageComboBox?

Hi Sascha,

(In reply to comment #85)

(In reply to comment #83)

(In reply to comment #81)

(In reply to comment #77)

I forgot one thing: The ctkPathLineEdit has recently changed by Julien to
include a browse button by default. I adapted the default CTK XSL fragment
(two weeks ago or something) but it looks like the MITK view still replaces
it with the ctkPathLineEdit and Browse button combination.

There is probably no need for an extra XSL file in MITK for the output
image. If I don't overlook something, instantiating the MITK combo box
widget in the QUiLoader sub-class should do(?).

Hi Sascha, I just pushed this:

OK, I just pushed to both branches.

(In reply to comment #78)

(In reply to comment #77)

Hi Sascha,

(In reply to comment #67)

Hi Sascha,

I just tried using the progress reporting in ctkCmdLineModuleFutureWatcher.
Unfortunately I didn't seem to get any output,

Hi Sascha,

Just pushed small fix for template parameters to CTK branch

I have to go do some marking of student projects now ... but can work on this now when I return. I was thinking:

(In reply to comment #57)

I just added the new ctkCmdLineModuleFutureWatcher class which provides
signals and methods to retrieve the standard output and error data.

It was a little tricky to get right, so I hope I did not overlook something
(there is a test for it). Additionally, the module explorer app makes use of
the new stuff. You can try for example the ctkCmdLineModuleTestBed module
and set the output number to non-zero.

Just pushed to CTK and MITK to include the ctkCmdLineModuleQtComboBox and ctkCmdLineModuleQtUiLoader.

(In reply to comment #56)

(In reply to comment #55)

Hi Sascha,

do you want me to move QmitkUiLoader, QmitkCmdLineModuleFactoryGui, or
QmitkCmdLineModuleGui into the CTK command line modules Qt GUI folder?
(with the obvious renaming and CTK-ifying included).

Yes, if you could provide a ctkCmdLineModuleQtUiLoader in the QtGui frontent
library, that would be great. For the QComboBox case, I think having a
private sub-class and instantiating it in the ctkCmdLineModuleQtUiLoader
class would be enough. Since we cannot use the "currentText" property of
QComboBox, we should probably change the default property name "currentText"
for enumerations to "currentEnumeration" (or similar) and provide a property
with that name in our internal QComboBox sub-class.

(In reply to comment #61)

Hi Sascha,

Hi Sascha,

Hi Sascha,

When I run my MITK plugin I get:

(In reply to comment #53)

(In reply to comment #50)
I guess your CTK subclass suggestion is a good one. But I am thinking about
providing the widget in the QtGui front-end and instantiating it in a new
custom QUiLoader (also contained in the QtGui front-end library). Projects
like MITK which need further customisation should then sub-class the
QUiLoader from the QtGui front-end (instead of sub-classing QUiLoader
directly). Does that sound reasonable?

12. CommandLineModulesView not thread safe, and can't run more than one at once, due to saving m_TemporaryFileNames and m_OutputDataToLoad.
13. MITK installation needs to put the ctk designer plugin libraries in the right place, to be found at run-time.

Just pushed, first working version running NiftyReg (reg_aladin) performing an affine registration. Saves images to temporary storage and when finished, loads any output data back in.

So, yes, I think we need your re-factoring, and the suggestion you have just made sounds good.

I just pushed CTK class and some method level doxygen updates for command line module stuff.

End of day, just did another push, fixing points 8 and 11.

Thats exactly the bit I just hit.

Just pushed, fixing the connection of the browse button for an image output... then realised we also had a missing xsl file.

Hi Sascha,

Questions/Issues remaining:

Hi Sascha,

(In reply to comment #32)

I now pushed the 199-create-a-directory-list-widget topic branch to the CTK
repository (using JC's branch with virtually no changes yet).

I also cherry-picked your changes in the cli-module-support branch (merging
was a mess because I wanted to drop the widget commits). Also did the
renaming stuff and merged the 199-create-a-directory-list-widget branch into
cli-module-support. Everything we have so far should now be available from
cli-module-support so we can use that branch for the MITK integration.

Feel free to push fixes to the cli-module-support branch on commontk/CTK.

(In reply to comment #26)

Nice! The watcher looks great :-)

I was thinking about adding signals like "moduleAdded(const
ctkCmdLineModuleReference&" and "moduleRemoved(const
ctkCmdLineModuleReference&)" to the ctkCmdLineModuleManager. Similar to the
events in a service registry. What do you think? Would we still need the
signals in the watcher?

Just pushed:

Hi there,

Just pushed to:

(In reply to comment #28)

(In reply to comment #27)

(In reply to comment #26)

I meant to ask if we would still need the signals from the
ctkCmdLineModuleDirectoryWatcher class. You are right, that connecting the
signals from QFileSystemWatch to the internals of
ctkCmdLineModuleDirectoryWatcher is necessary, but when registering new
modules within the cmdlinemodwatcher with the cmdlinemodmgr, the manager
would emit a "moduleAdded(...)" signal to which people could connect
(instead of connecting to the cmdlinemodwatchter). Does it make sense?

I just pushed again to those two branches.

Just pushed to both branches again, adding support for QmitkDataStorageComboBox without the extra unnecessary Browse button

Hi Sascha,

Hi Sascha,

Hi Sascha,

I just pushed 3 commits to:

Just thought I would upload a screenshot of the current progress. Pointing the search path at the slicer folder, we can load 2 of the 100 or so existing slicer modules. We currently have incompatible XML, and probably some parameters missing.

Question: Do we have anything that would test if a file is/is not a loadable
module without throwing error messages or warnings? If we scan a directory,
the only way is to try running it and retrieving the XML isn't it?

Screenshot Wednesday - loading Slicers EMSegment

(In reply to comment #7)

Looking good so far. I am still working on completing the API implementation

• especially support for running the modules and getting (progress) feedback.

Hi Sascha, I just pushed CTK:

(In reply to comment #15)

Yeah, that was a bug :-) I just pushed a commit doing exactly what you
proposed.

OK, I will sort out directory scanning and hopefully QFileSystemWatcher.
I can also look at those widgets, we can do a CTK one, if one does not already exist. It might be a bit "prototypey" this week, and need refining later.

I started a new comment to avoid interleaving too many comment/reply levels.

(In reply to comment #5)

(In reply to comment #4)

• Copy the libCTKWidgetsPlugins.so file to MITK-build/bin/designer/

This one fixed it, although I had to manually create the MITK-build/bin/designer folder.

Hi there,

Obviously work in progress: