Hi Sascha,

I fixed up NiftyReg XML to be CTK compliant here:

http://niftyreg.svn.sourceforge.net/viewvc/niftyreg?view=revision&revision=311

I added checkbox to main MITK CLI view so as we toggle it on/off you can switch the ctkCmdLineModuleManager to register in silent/not silent mode:

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

I also pushed minor tweaks to CTK:

https://github.com/MattClarkson/CTK/tree/matt-cli-module-support

So today, hopefully i have addressed points 2,8,9 in the list above. Point 7 could be skipped for now. So, tomorrow I will need to be doing step 10, so I would love to hear about Ivo's progress.

• update ---

OK, i just read your most recent posting. I can do that ctk class ctkCmdLineModuleDirectoryWatcher in the morning, so will still need Ivo's stuff, if not, I will give it a go tomorrow.

Bye

Thanks

Matt

(In reply to comment #22)

I also pushed minor tweaks to CTK:

https://github.com/MattClarkson/CTK/tree/matt-cli-module-support

Great, hopefully I can discuss the widget integration into CTK with Julien on Friday.

So today, hopefully i have addressed points 2,8,9 in the list above. Point 7
could be skipped for now. So, tomorrow I will need to be doing step 10, so I
would love to hear about Ivo's progress.

We haven't had time to create a useful imaging cli module yet. Running modules is also still in the works and passing data is also missing.

OK, i just read your most recent posting. I can do that ctk class
ctkCmdLineModuleDirectoryWatcher in the morning, so will still need Ivo's
stuff, if not, I will give it a go tomorrow.

I think the watcher would be great. Given the list of missing items above, we seem to still need to invest some more work in the infrastructure for a useful cli module support in MITK. However an somehow useful imaging module is definitely also needed.

Hi Sascha,

unfortunately, no progress at all today ... ZERO.

I got sidetracked by my normal work.
:-(

Matt

Yay ... Progress!

I just pushed 3 commits to:

https://github.com/MattClarkson/CTK/tree/matt-cli-module-support

and 1 commit to:

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

implementing functionality to add/remove folders, and add/remove executables from those folders, and the GUI updates automatically without restart. Currently Im jut putting creating QMenu widget on the fly with the loaded module names in.

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?

About the directory widget, do you mind if I use your commits and create a branch in the CTK repository? I think this makes it little easier to merge the branch into master and into the cli branch.

(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?

Er ... I don't quite understand. If we put signals on the ctkCmdLineModuleManager we can inform other people when modules removed, but it is the signals from the QFileSystemWatcher that trigger the removal, so we can't get rid of them... Or did I miss something.

About the directory widget, do you mind if I use your commits and create a
branch in the CTK repository? I think this makes it little easier to merge
the branch into master and into the cli branch.

I am away for 2 days at an offsite. So, please feel free.

(In reply to comment #27)

(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?

Er ... I don't quite understand. If we put signals on the
ctkCmdLineModuleManager we can inform other people when modules removed, but
it is the signals from the QFileSystemWatcher that trigger the removal, so
we can't get rid of them... Or did I miss something.

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?

About the directory widget, do you mind if I use your commits and create a
branch in the CTK repository? I think this makes it little easier to merge
the branch into master and into the cli branch.

I am away for 2 days at an offsite. So, please feel free.

All right.

(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?

Ah, yes. That would probably be better, as it was a bit strange having to connect the signal from the ctkCmdLineModuleDirectoryWatcherPrivate to the ctkCmdLineDirectoryWatcher, just to emit the moduleChanged signal. Its probably best coming from the manager. I can do that tomorrow.

Hi there,

I just pushed to the same MITK and CTK branch, moving those signals onto the ctkCmdLineModuleManager.

Now I really need to get it running NiftyReg.

What's the status with the actual "running a process bit". I saw some changes at the end of last week, but did not have time to take a look.

I might be able to take a look tonight, so, any status updates ... send them my way!

(In reply to comment #30)

Hi there,

I just pushed to the same MITK and CTK branch, moving those signals onto the
ctkCmdLineModuleManager.

Great. We should merge your branch into the CTK cli branch soon... I will hopefully have some time today to give it a try.

Now I really need to get it running NiftyReg.

Do you already have a plan how to pass the input data? Haven't thought about that yet...

What's the status with the actual "running a process bit". I saw some
changes at the end of last week, but did not have time to take a look.

I just pushed a working state for that. It is not finished, but you can now do ModuleInstance->run(). The returned QFuture supports only the "finished" signal and "waitForFinished" for now. Note that there will be now output from the running cmdlinemodule on the console yet.

I might be able to take a look tonight, so, any status updates ... send them
my way!

There is initial work for watching progress updates, but it is not working yet. We also need to rename *Private.h files to *_p.h files (we decided to use only this naming convention for private headers to be consistent).

I am also thinking about renaming *ModuleInstance files/classes to just *Module.

Then some more polishing on the ModuleManager API and I think we are good to go for master.

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 #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.

Understood, so my dev environment now using:

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

updated to take the main https://github.com/commontk/CTK/tree/cli-module-support

and all up-to-date.

Just pushed to:

https://github.com/commontk/CTK/tree/cli-module-support

and

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

first version with QmitkDataStorageComboBox showing images.

Just pushed:

https://github.com/MattClarkson/MITK/commit/f40711efdf31bcab7dfb04d8f4cdad9393b3a11f

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

Hi Sascha,

I have hit the following scenario. For images that should be specified as "input" to a command line module, we can use QmitkDataStorageComboBox, as they should already be loaded. For output images, we cannot use this, as we should use the standard ctkPathLineEdit (for consistency sake). This means, I need to generate different widgets depending on the channel parameter in the XML. The same would be true for both image and file types. So, I am currently working towards generating different widgets for input and output for both image and file types. (I don't know what the geometry type is for at this stage, though the same may apply for that).

Let me know if this is the wrong thing to do.

Matt

I just pushed again to those two branches.

I split the XML so that you can have a different widget for

1. image input
2. image output
3. file (and geometry) input
4. file (and geometry) output

and then on the MITK branch, we only have to override the image input

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

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.

Questions/Issues remaining:

1. ctkCmdLineModuleObjectTreeWalker exposes currentObject() method? Any better suggestions?
2. Seeding random number generator in ExtApp executable? Any better suggestions?
3. Progress reporting limited.
4. We are providing QmitkDataStorageComboBox for input images, and the selection is a bit wierd, as you have to be able to model "no selection" better. At the moment, I select the command line module, then load image, then select ref and floating images.
5. Need to improve how we select the temporary folder.
6. Unit tests in CTK for the classes I have written.
7. We previously mentioned improving the ctkDirectoryListWidget, and that also means unit tests.
8. Documentation.
9. Ability to pause/resume, or just kill a command line app.
10. Need longer conversation on image format handling. I had problems running NiftyReg using .nrrd so I switched to nifti.
11. Improve the visible documentation in About and Help tabs.

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.

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

Hi Sascha,

Right, command line module is working ok, up to the point that I need your input.

Current issues are (keeping numbers from above).

1. ctkCmdLineModuleObjectTreeWalker exposes currentObject() when walking object tree. Is this a bad idea? I needed the object type in CommandLineModulesView.cpp.
2. I'm seeding random number generator in ExtApp executable to provide random temporary file names in CommandLineModulesView.cpp. This should be done else where or else other apps wont have it. Do we really need it? Actually, we could just suffice with sequential numbers.
3. As mentioned by you previously, there is currently no console output for running apps, which I'm presuming you will work on :-)
4. Unit tests for ctk widgets.
5. Improve ctkDirectoryListWidget.
6. Ability to pause/resume, or just kill a command line app.
7. Currently using nifti format.
8. CommandLineModulesView not thread safe, and can't run more than one at once, due to saving m_TemporaryFileNames and m_OutputDataToLoad.
9. MITK installation needs to put the ctk designer plugin libraries in the right place, to be found at run-time.
10. No way to reset to default params currently.

with 4, 5, 8, 11, now provisionally fixed.

I have to leave this for a few days now (a week or so), as I have other stuff to do.

In order of preference, I would say:

13, 3, 9, 12, 14, 10 ... then any order.

All the best.

Matt

Hi,

Wow, you made a lot of progress!

(In reply to comment #44)

Current issues are (keeping numbers from above).

1. ctkCmdLineModuleObjectTreeWalker exposes currentObject() when walking

object tree. Is this a bad idea? I needed the object type in
CommandLineModulesView.cpp.

I was wondering why that even could work :-) The ctkCmdLineModuleObjectTreeWalker class is not exported, but you are probably working with a gcc < 4.5 where symbol visibility is default (instead of hidden). Windows compilers or gcc >= 4.5 should give you linker errors with that approach.

Anyway, I think we can do without ctkCmdLineModuleObjectTreeWalker (which I would like to keep as an implementation detail of the Qt Gui factory).

The ctkCmdLineModule class has a "QVariant value(const QString& parameter)" method which should do the job with a little help. In the Qt case, that method looks up the name of a QObject property which it uses to retrieve the current property value. In the default XSL file, the default property name is "value" and for the other default widget types the correct property name is saved as the value of another dynamic QObject property, which always has the same name. See the "ctk:mapTypeToQtValueProperty" XSL function and the named template "commonWidgetProperties" setting the "parameter:valueProperty".

For custom widgets, we cannot (yet) customize the default XSL file to use other property names (e.g. "currentIndex" for a QComboBox) (for setting default values and retrieving the current value). But I think you can maybe just "overwrite" the QObject property "parameter:valueProperty" after <xsl:call-template name="commonWidgetProperties"/> in your QmitkDataStorageComboBox.xsl.

The property should probably contain the current selection of the QmitkDataStorageComboBox as a mitk::DataNode::Pointer object in a QVariant. See QmitkCustomVariants.h.

With that, ctkCmdLineModule::value(parameterName) should return a QVariant containing a mitk::DataNode::Pointer. You probably will have to use ctkCmdLineModuleDescription to collect all input parameters for the "image" type.

2. I'm seeding random number generator in ExtApp executable to provide

random temporary file names in CommandLineModulesView.cpp. This should be
done else where or else other apps wont have it. Do we really need it?
Actually, we could just suffice with sequential numbers.

I don't know. Does it hurt to just call qsrand() somewhere in the plug-in code, potentially "re-seeding" the generator?

3. As mentioned by you previously, there is currently no console output for

running apps, which I'm presuming you will work on :-)

Yes, at least the messages written to std::cerr will be available through the QFuture stuff. Maybe we can provide text written to std::cout too.

6. Unit tests for ctk widgets.
7. Improve ctkDirectoryListWidget.

I plan to get that one into "mergeable state soon", see below.

9. Ability to pause/resume, or just kill a command line app.

That is working already (use the QFuture object).

10. Currently using nifti format.
11. CommandLineModulesView not thread safe, and can't run more than one at

once, due to saving m_TemporaryFileNames and m_OutputDataToLoad.

We could think about using the "allowMultiple" XML attribute in the view extension declaration and allow users to create another instance of CommandLineModulesView...

13. MITK installation needs to put the ctk designer plugin libraries in the

right place, to be found at run-time.

Yes, we should create a separate bug for that.

14. No way to reset to default params currently.

You could get all ctkCmdLineModuleParameter objects from the ctkCmdLineModuleDescription and retrieve the default value and set it using ctkCmdLineModule::setValue(...). A convenience method would be nice though.

with 4, 5, 8, 11, now provisionally fixed.

Awesome! :-)

I have to leave this for a few days now (a week or so), as I have other
stuff to do.

Due to some severe time constraints on my behalf, I would like to get the current branch merged soon. I think we are close. I need to

a. finish my frontend/backend separation
b. make ctkDirectoryListWidget "good enough" for merging
c. make ctkCmdLineModuleManager thread-safe
d. implemented a simple caching strategy for XML descriptions
e. provide some convenience methods for working with module values

In order of preference, I would say:

13, 3, 9, 12, 14, 10 ... then any order.

Fine with me.

Thanks,
Sascha

(In reply to comment #45)

The ctkCmdLineModule class has a "QVariant value(const QString& parameter)"
method which should do the job with a little help. In the Qt case, that
method looks up the name of a QObject property which it uses to retrieve the
current property value. In the default XSL file, the default property name
is "value" and for the other default widget types the correct property name
is saved as the value of another dynamic QObject property, which always has
the same name. See the "ctk:mapTypeToQtValueProperty" XSL function and the
named template "commonWidgetProperties" setting the
"parameter:valueProperty".

For custom widgets, we cannot (yet) customize the default XSL file to use
other property names (e.g. "currentIndex" for a QComboBox) (for setting
default values and retrieving the current value). But I think you can maybe
just "overwrite" the QObject property "parameter:valueProperty" after
<xsl:call-template name="commonWidgetProperties"/> in your
QmitkDataStorageComboBox.xsl.

The property should probably contain the current selection of the
QmitkDataStorageComboBox as a mitk::DataNode::Pointer object in a QVariant.
See QmitkCustomVariants.h.

With that, ctkCmdLineModule::value(parameterName) should return a QVariant
containing a mitk::DataNode::Pointer. You probably will have to use
ctkCmdLineModuleDescription to collect all input parameters for the "image"
type.

Okay, I wasn't considering that the command line generating code needs a different "value" (the path to the file in the filesystem) than the pre-processing code in the MITK plug-in (which needs the mitk::DataNode::Pointer).

Maybe we change

QVariant ctkCmdLineModule::value(const QString& parameterName)

to

QVariant ctkCmdLineModule::value(const QString& parameterName,

int role = ctkCmdLineModule::LocalResourceRole)

and have in ctkCmdLineModule the enum

enum ParameterValueRole {

/* Data returned using this role must no be of any type not supported by
   QVariant by default. For complex parameter types (like file, image,
   geometry, etc.) the data must be convertible to a QString pointing
   to a local resource.
 */
LocalResourceRole = 0,

/* This role can be used in custom frontends to return a QVariant
   containing for example an in-memory representation of a complex object.
   One can then either convert the in-memory representation to a local
   resource before running a module such that arbitrary backends relying on
   the LocalResourceRole can process the data. Or one creates a custom
   backend which knows how to handle QVariants returned by this role.
 */
UserRole = 8

}

and custom factories (frontends) provide a "ctkCmdLineModule::value(...)" implementation which can return special QVariants for certain parameter types and "roles".

I already used the frontend/backend terminology here (due to my refactoring) but I guess you know what I mean.

What do you think?

Thats exactly the bit I just hit.

I have just:

1. In the MITK plugin, removed references to ObjectTreeWalker.
2. Changed QmitkDataStorageComboBox.xsl to override the property:valueProperty with QmitkDataStorageComboBoxWithSelectNode::GetSelectedNode
3. Declared the property in QmitkDataStorageComboBoxWithSelectNode and registered the custom type in the MITK plugin.
4. Changed the logic so that if the ctkCmdLineModuleParameter is an channel="input" and tag="image", then we get hold of the mitk::DataNode, and if it is non-null, we generate the unique file name and save.

All that now works, EXCEPT, I can't store back the full filename.

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.

When I run my MITK plugin I get:

QComboBox::setProperty: Property "currentText" invalid, read-only or does not exist
QComboBox::setProperty: Property "currentText" invalid, read-only or does not exist

I believe this is because in CTK/Libs/CommandLineModules/Core/ctkCmdLineModuleXslTransform.cpp

we specify that QComboBox is the default for enumerations, but QComboBox does not have setCurrentText.

Should a CTK subclass be provided or is there a way to override the XSL just for the setter?

Hi Sascha,

i just pushed to both the CTK and MITK branches:

https://github.com/commontk/CTK/commits/cli-module-support

and

https://github.com/MattClarkson/MITK/commits/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

Working from that list above, with items 1-14. I think:

1, 2, 4, 5, 8, 9, 10, 11, 14 are fixed.

A few points.

3. You say there is std::cerr output from QFuture, but I don't get any output other than a start and finish status. It could also be the case that NiftyReg only uses std::cout. Is the code all in place, or are you still working on it? Or am I using it wrong?

6,7. Your previous comment says that you plan to get this to a "mergeable" state soon.. so I am not looking at this.

12. The view is not thread safe, but I have made efforts such that GUI controls are enabled/disabled at the right point, so the user cannot launch more than one at once. Is there a way to get a PID back from the running process, because then, when I store a list of temporary files, and a list of output files, I could put them in a QHash<int=PID, QList<QString>> sort of thing, and organise them by PID, and so run more than one at once. But this is optional, and I would probably prefer to leave it with your suggestion of maybe allowing more than one instance of the View itself.

13. With T12896, it looked on my Mac like the .ini file was working, as I have never been able to generate the GUI on my mac before, and when I ran make install, the CTK Designer plugin libraries appeared in the right place. It may require further testing on Windows/Linux, but so far so good.

14. Thanks for providing the reset method in the ctkCmdLineModuleFronted. I have now implemented a restore default parameters option.

I also added a basic QPlainTextEdit so the user can see the log statements and placed it within the actual view, within a ctkCollapsibleGroupBox so the user can close it if it is not necessary. I also ran NiftyReg's program reg_aladin and performed affine registration, and the registered image is indeed registered!

I also merged from master to this branch. I did try a rebase, but it went wrong... or I was stupid.. or something. :-)

So, apart from console output, I think the plugin is looking quite usable.

Can you advise on the whereabouts of std::cerr and std::cout progress updates?

Thanks as always.

Matt

Hi,

(In reply to comment #51)

Hi Sascha,

i just pushed to both the CTK and MITK branches:

https://github.com/commontk/CTK/commits/cli-module-support

Thanks for fixing my stupid mistakes.

Working from that list above, with items 1-14. I think:

1, 2, 4, 5, 8, 9, 10, 11, 14 are fixed.

Great. I will still work on 8 (Documentation).

A few points.

3. You say there is std::cerr output from QFuture, but I don't get any

output other than a start and finish status. It could also be the case that
NiftyReg only uses std::cout. Is the code all in place, or are you still
working on it? Or am I using it wrong?

Getting the complete std::cerr output via the last progress event *should* work, according to

https://github.com/commontk/CTK/blob/cli-module-support/Libs/CommandLineModules/Backend/LocalProcess/ctkCmdLineModuleProcessTask.cpp#L102

but I didn't test it recently (there is no unit test for it yet). However, I am not completely content with that solution, see my comments below.

6,7. Your previous comment says that you plan to get this to a "mergeable"
state soon.. so I am not looking at this.

Yes, I started working on it.

12. The view is not thread safe, but I have made efforts such that GUI

controls are enabled/disabled at the right point, so the user cannot launch
more than one at once. Is there a way to get a PID back from the running
process, because then, when I store a list of temporary files, and a list of
output files, I could put them in a QHash<int=PID, QList<QString>> sort of
thing, and organise them by PID, and so run more than one at once. But this
is optional, and I would probably prefer to leave it with your suggestion of
maybe allowing more than one instance of the View itself.

I think disabling the GUI controls is fine, maybe allowing a second instance of a ctkCmdLineModuleFrontend implementation for the same module reference. We could probably enhance the local process backend somehow to get access to the PID... but maybe you can just use the future returned by the run function as the key in your map (it should relate one-to-one to the running process or whatever the backend used).

13. With T12896, it looked on my Mac like the .ini file was working, as I

have never been able to generate the GUI on my mac before, and when I ran
make install, the CTK Designer plugin libraries appeared in the right place.
It may require further testing on Windows/Linux, but so far so good.

Good. I forgot to mention that I only tested the modifications on Linux and Windows but not on a Mac yet. Seems it is working on all platforms.

14. Thanks for providing the reset method in the ctkCmdLineModuleFronted. I

have now implemented a restore default parameters option.

I also added a basic QPlainTextEdit so the user can see the log statements
and placed it within the actual view, within a ctkCollapsibleGroupBox so the
user can close it if it is not necessary. I also ran NiftyReg's program
reg_aladin and performed affine registration, and the registered image is
indeed registered!

Very cool! :-)

I also merged from master to this branch. I did try a rebase, but it went
wrong... or I was stupid.. or something. :-)

Yeah... rebasing a published branch isn't a good idea anyway. Should be fine.

So, apart from console output, I think the plugin is looking quite usable.

Can you advise on the whereabouts of std::cerr and std::cout progress
updates?

As mentioned above, I am not really satisfied with the current solution and have thought about it already some time ago...

First I tried to use the "setProgessValueAndText()" method from the QFutureInterface to generate progress events containing messages. That works when the module prints "real" progress information using the Slicer XML dialect (http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation#Showing_Progress_in_an_Application) and the text from the "filter-comment" XML tag will be used as the progress text reported by the QFuture ("filter-comment" can also appear as a child element in "filter-progress" in the CTK ctkCmdLineModuleXmlProgressWatcher implementation although it is not specified like that on the Slicer wiki page).

However, I think we cannot use that approach for ordinary cout or cerr output - the main problem being the need of a strictly monotonic increasing progress value when reporting progress (with a progress text part of the cout or cerr output). Otherwise, the QFutureInterface class will not send progress reports.

So maybe we can enhance our current ctkCmdLineModuleFuture class by adding the two methods

QString outputText() const;
QString errorText() const;

and add reporting functions in our ctkCmdLineModuleFutureInterface specialization

appendOutputText(const QString&)
appendErrorText(const QString&)

I can maybe try implementing something like that tomorrow.

(In reply to comment #50)

When I run my MITK plugin I get:

QComboBox::setProperty: Property "currentText" invalid, read-only or does
not exist
QComboBox::setProperty: Property "currentText" invalid, read-only or does
not exist

I believe this is because in
CTK/Libs/CommandLineModules/Core/ctkCmdLineModuleXslTransform.cpp

we specify that QComboBox is the default for enumerations, but QComboBox
does not have setCurrentText.

Oh, right. We implicitly require the property to have READ and WRITE methods. This assumption fails for "currentText" of QComboBox.

Should a CTK subclass be provided or is there a way to override the XSL just
for the setter?

We could introduce a second property (in addition to "parameter:valueProperty") containing the name of a property which can be set, but in case of QComboBox it seems to get quite complicated because the types for "currentText" and "currentIndex" (for example) do not match, so for example resetting the frontend values to their default will get complicated...

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?

(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?

Sure, sounds good.

Hi Sascha,

I just updated my MITK stuff here:

https://github.com/MattClarkson/MITK/commit/f27e47683a52c3bdfb00ed1a8ad8907b3abffc77

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).

I also noticed that you have done more work to provide progress bars, and properly handle pause/cancel stuff, and my MITK plugin implementation was a bit simplistic perhaps. But if I wanted to use the stuff in CTK/Applications/ctkCommandLineModuleExplorer in my MITK plugin, then it would have to be moved back into CTK/Libs/CommandLineModules, presumably in the Frontend/QtGui folder.

I also specifically made a QmitkDirectoryListWidget using the newly provided ctkPathListWidget, and ctkPathListButtonsWidget, as from an application perspective, we I wanted the user to just see/select directories, but I get the feeling that I have just lost some flexibility. I notice that in your ctkCommandLineModuleExplorer example app, you provide the ability to scan directory, and also specifically select modules... which is good if you want to cherry pick some apps in a directory full of other stuff.... so maybe I need more work in the MITK plugin.

Best

Matt

(In reply to comment #55)

Hi Sascha,

I just updated my MITK stuff here:

https://github.com/MattClarkson/MITK/commit/
f27e47683a52c3bdfb00ed1a8ad8907b3abffc77

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.

I also noticed that you have done more work to provide progress bars, and
properly handle pause/cancel stuff, and my MITK plugin implementation was a
bit simplistic perhaps. But if I wanted to use the stuff in
CTK/Applications/ctkCommandLineModuleExplorer in my MITK plugin, then it
would have to be moved back into CTK/Libs/CommandLineModules, presumably in
the Frontend/QtGui folder.

Yes, but the progress bar widget is yet unfinished. I am also no sure about the added value when moving it to the QtGui library. Maybe the progress notification requirements are too application specific to warrant a general purpose widget...?

But please feel free to copy that code in your MITK plug-in for the time being.

I also specifically made a QmitkDirectoryListWidget using the newly provided
ctkPathListWidget, and ctkPathListButtonsWidget, as from an application
perspective, we I wanted the user to just see/select directories, but I get
the feeling that I have just lost some flexibility. I notice that in your
ctkCommandLineModuleExplorer example app, you provide the ability to scan
directory, and also specifically select modules... which is good if you want
to cherry pick some apps in a directory full of other stuff.... so maybe I
need more work in the MITK plugin.

Yeah, maybe... it probably depends. If you assume that users will "retrieve" modules from somewhere and put it into a central location, having just a directory scanning would be fine.

I will also have a look at the console output reporting stuff.

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.

(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.

understood. Hopefully I will get back on this next week.

(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.

understood. Hopefully I will get back on this next week.

Just pushed small fix for template parameters to CTK branch

https://github.com/commontk/CTK/commits/cli-module-support

hope this is right ... it compiles now on my Mac and Linux machine.

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

Question:

In my MITK view, I use a ctkMenuComboBox from the CTK widgets folder. But I use a dumb method for generating the Menu, which is currently implemented in ctkCmdLineModuleMenuFactoryQtGui. Ideally I want a ctkMenuComboBox that is aware of the ctkCmdLineModuleManager, and automatically updates itself. So I was thinking of subclassing ctkMenuComboBox injecting the ctkCmdLineModuleManager via a constructor argument, and implementing a new widget, and put it in the FrontEnd/QtGui folder, but then the CommandLineModules lib is dependent on the Widgets lib.

Is that OK?

(In reply to comment #61)

Is that OK?

Hmmm ... probably not, as you don't want to turn on the whole Widgets library just for this. I will put my new widget in the MITK plugin.

(In reply to comment #62)

Looks good!

Is that OK?

Hmmm ... probably not, as you don't want to turn on the whole Widgets
library just for this. I will put my new widget in the MITK plugin.

I think you are right. Moving the menu/combobox stuff to MITK is probably a good idea.

I just pushed a couple of fixes and features:

Most notably, watching console output on the standard output and error channel now works via the ctkCmdLineModuleFutureWatcher class.

I took the liberty to hide your ctkCmdLineModuleQtComboBox class in the ctkCmdLineModuleQtUiLoader.cpp file.

As you already suspected, I had to add a "role" argument to the "setValue()" method too.

Fixed handling of <channel> elements such that it is possible to add them to all parameter types.

Fixed missing constraints in the XSL file and disabling simple output parameters (those with an index value of 1000) by default.

Added XSL parameters for configuring the Qt object property name which is used by the new DisplayRole role in "setValue()" and "value()".

I think we achieved *a lot* now. I will write rudimentary documentation on the week-end and merge the CTK branch to the master and update the CTK version in MITK for the next release.

Cool.

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

1. Provide a better ctkMenuComboBox on the MITK side, as nested menus like Slicer will help.

2. The first thing any Slicer user will do will point this MITK plugin at their Slicer installation, and most command line modules will fail because the XML is invalid, and then people will say "the MITK plugin doesn't work", so I will provide an optional preference in the MITK GUI to decide the level of strictness of XML validation.

3. I am still thinking about how to nicely allow multiple jobs to be run, and see multiple log files of output. It should all be possible with your new future watcher stuff.... I assume .... if there is a log file of all the output with each watcher? or is it always incremental? At the moment my MITK gui just disables the widgets while one command line module is running, which isn't very nice.

4. The use of a tab widget in the front end is a bit pointless/useless/annoying, especially if you want to do point 3.

Got to go.

(In reply to comment #65)

Cool.

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

1. Provide a better ctkMenuComboBox on the MITK side, as nested menus like

Slicer will help.

Sounds good. We could certainly also hack our way from the plug-in into the main menu bar, if you are interested (we already have such hacks, so I don't care about one more).

2. The first thing any Slicer user will do will point this MITK plugin at

their Slicer installation, and most command line modules will fail because
the XML is invalid, and then people will say "the MITK plugin doesn't work",
so I will provide an optional preference in the MITK GUI to decide the level
of strictness of XML validation.

Yeah, very true. I will try and add a test for the different validation modes and error messages.

3. I am still thinking about how to nicely allow multiple jobs to be run,

and see multiple log files of output. It should all be possible with your
new future watcher stuff.... I assume .... if there is a log file of all the
output with each watcher? or is it always incremental? At the moment my MITK
gui just disables the widgets while one command line module is running,
which isn't very nice.

Yes, I'm not sure about the best way for MITK either. Running one ctkCmdLineModuleFrontend multiple times should work fine. The ctkCmdLineModuleFuture returned by the ctkCmdLineModuleManager::run(...) method is self-contained and represents the running module (independently of a specific ctkCmdLineModuleFrontend instance). The console output can be read incrementally (using the future watcher) or all at once (using the future itself or a connected watcher).

4. The use of a tab widget in the front end is a bit

pointless/useless/annoying, especially if you want to do point 3.

True. I'm not at all sure about the best user experience for running a module multiple times.

Either

(a) allowing to "run" one front end multiple times (and have a separate view for console and result reports) or

(b) disabling the front end when it is run (than it could contain its own console and result reports) but allow multiple front ends for the same module?

Case (a) would be easier to do with regard to the BlueBerry workbench specific code, but it will mean more management work for the cli plug-in. In case (b), we could off-load the management of multiple front-ends to the workbench by using the "secondary id" for views with "multiple=true". Meaning, we could have one central view containing only the module GUI and maybe start/pause/cancel buttons (output reporting maybe integrated or in a separate view) which can be instantiated by the application multiple times with different secondary ids. For example there could be three module front-ends, two for the same module and one for another, all using the same view implementation but with different compount ids:

org.mitk.views.cli:<module-id-1>#1
org.mitk.views.cli:<module-id-1>#2
org.mitk.views.cli:<module-id-2>#1

Just thinking loud here...

Hi Sascha,

I just tried using the progress reporting in ctkCmdLineModuleFutureWatcher. Unfortunately I didn't seem to get any output, and also unfortunately Im away now until Friday night. I pushed my code, just incase you want to take a look.

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

I would still like to update ctkCmdLineModuleDirectoryWatcher to watch for files. This way, we can specify directories to watch, or individual executables to watch.

Apart from that (and the progress reporting), the CTK functionality appears to all be there.

The changes that I still want to do are on the MITK side. I was thinking of providing a table widget, where each row has a pause/resume button, a cancel button, a progress bar, and a button to remove the row itself from the table. Each row could contain its own Future and FutureWatcher, list of outputs to load on finish etc. So, the table widget would essentially act like a job manager, and the user could launch multiple jobs in succession. It would also be possible to retrieve the console output for each job from the FutureWatcher. I think this could be a nice GUI then. I would also remove the current tab widget I have in the central area, and just have one current GUI front end. If the user selects a different module, the GUI changes, and replaces the previous one. If you have the table widget as a job manager, if a job is running then switching modules wont matter, and if the user selects different modules from the menu in succession without launching them, then it wont matter if we replace the GUI. i.e we dont need the tabs. The table widget could also provide a popup widget with the console output, triggered by hovering over it.

What do you think?

(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,

I forgot to say, Im testing on a Mac, Snow Leopard, gcc 4.2.1. I will try and have a proper debug next weekend. I just thought I would tell you in-case you wanted to merge to master.

[f16b12]: Merge branch 'bug-12506-update-ctk'

Merged commits:

2012-09-04 16:09:06 Sascha Zelzer [432903]
Use updated CTK with command line module support.

[203c1d]: Merge branch 'bug-12506-update-ctk'

Merged commits:

2012-09-04 18:00:01 Sascha Zelzer [14ccbc]
COMP: Update CTK to fix compiler errors on some compilers.

[5d2306]: Merge branch 'bug-12506-update-ctk'

Merged commits:

2012-09-04 18:52:37 Sascha Zelzer [fe0181]
COMP: Update CTK to fix ctkCoordinatesWidget Windows compiler error.

(In reply to comment #67)

The changes that I still want to do are on the MITK side. I was thinking of
providing a table widget, where each row has a pause/resume button, a cancel
button, a progress bar, and a button to remove the row itself from the
table. Each row could contain its own Future and FutureWatcher, list of
outputs to load on finish etc. So, the table widget would essentially act
like a job manager, and the user could launch multiple jobs in succession.
It would also be possible to retrieve the console output for each job from
the FutureWatcher. I think this could be a nice GUI then. I would also
remove the current tab widget I have in the central area, and just have one
current GUI front end. If the user selects a different module, the GUI
changes, and replaces the previous one. If you have the table widget as a
job manager, if a job is running then switching modules wont matter, and if
the user selects different modules from the menu in succession without
launching them, then it wont matter if we replace the GUI. i.e we dont need
the tabs. The table widget could also provide a popup widget with the
console output, triggered by hovering over it.

What do you think?

I think removing the tab widget in the view is a good idea. Switching modules by replacing the GUI sounds good, if we are going to have a central "job manager" view. I was also thinking the instead of the combobox/menu hybrid widget, we could use a real QMenuBar or QToolBar widget in the view, containing a drop-down menu for the available modules and start/stop/pause buttons. Or we move that menu into the applications main menu bar and open new views for each module frontend.

I am not sure about the popup widget in the table widget containing the console output though. I can imagine that the tooltip contents could get quite large, depending on the module. This could maybe make copying relevant information from the output cumbersome.

Just FYI, we had a student some time ago who implemented the Eclipse Jobs API in the org.blueberry.core.jobs plug-in. Unfortunately, there was not enough time to also implement the "Jobs View", which would have been perfect for integrating information about running modules...

Hi Sascha,

I just pushed to:

https://github.com/commontk/CTK/commits/cli-module-support

and

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

I have:

1. Provided nested menus in QmitkCmdLineModuleMenuComboBox, nested by using Category and Title tags, as I believe Slicer does.

2. Provided different layout. Removed tab widget. Refactored stuff out of CommandLineModulesView into QmitkCmdLineModuleProgressWidget.

3. Provided progress bar, pause, resume, stop, remove (based on your CTK example), and also a console output for each module.

4. Enabled multiple (currently unlimited ... or only limited by common sense), modules to be run simultaneously.

5. Provided user preference to specify individual command line executables rather than just directory scanning - requiring a new CTK version.

6. Provided user preference for XML validation level - but not really tested it much.

7. Updated doxygen.

So, I believe that the functionality is sufficient. So I would value your thoughts. There are bits I need to re-test, but possibly throwing it out to a wider audience might help here. That problem with progress output seems to be from NiftyReg, as other examples are updating properly. I will try and test this tomorrow.

[7e8f3e]: Merge branch 'bug-12506-update-ctk'

Merged commits:

2012-09-13 17:47:20 Sascha Zelzer [8953bd]
Use CTK with fixes for Qt 4.6 support.

Hi Sascha,

I just pushed to CTK/cli-module-support and to

https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

For the issues you raised:

On a clean start (without any directories/modules registered), pressing the magnifying class icon in the CLI view two times in a row crashes the app

This is raised as CTK issue https://github.com/commontk/CTK/issues/236
and checked in on branch
https://github.com/commontk/CTK/tree/236-ctkMenuComboBox-crash-if-no-menu-and-press-magnifying-glass

I have not really had time to test anything else with regards to this point, but I thought it should be a separate issue.

Minimum size for the gui seems too high (horizontal scroll bar is displayed)

I made it a bit smaller (removed the word "choose"), but its very dependent on the contents of the XML anyway.

On Linux the About/Help box sticks very close to the "Parameters" heading (see screenshot)

I made them group boxes for consistency with the other parameter group widgets.

On Linux when choosing different views, the gui is "overlayed" (see screenshot)

I refactored a lot, and re-introduced the tab widget again. I think it works quite nicely now, and it is easy and obvious to launch multiple jobs for the same module.

I also:

1. Added a user preference to control the maximum number of concurrent processes
2. Made XML validation error strings available as tab tool-tips
3. Updated doxygen.

I did also make a minor change to the cli-module-support branch that will be needed for the MITK branch to compile.

If the cli-module-support is merged to master again, and issue 236 merged to master, then the MITK branch could be nearing completion.

What do you think?

Also, feel free to update your MITK branch and see new screenshots.

Matt

(In reply to comment #75)

On a clean start (without any directories/modules registered), pressing the magnifying class icon in the CLI view two times in a row crashes the app

This is raised as CTK issue https://github.com/commontk/CTK/issues/236
and checked in on branch
https://github.com/commontk/CTK/tree/236-ctkMenuComboBox-crash-if-no-menu-
and-press-magnifying-glass

I have not really had time to test anything else with regards to this point,
but I thought it should be a separate issue.

Looks good to me, I just pinged J2 to have a look, but shouldn't be a problem.

Minimum size for the gui seems too high (horizontal scroll bar is displayed)

I made it a bit smaller (removed the word "choose"), but its very dependent
on the contents of the XML anyway.

Hmm, it looks like the ctkPathLineEdit widget has a too large minimum width.

I refactored a lot, and re-introduced the tab widget again. I think it works
quite nicely now, and it is easy and obvious to launch multiple jobs for the
same module.

Wow. I think the intention is much clearer now. The added widgets containing the progress bar also include the parameter gui. Is this intentional? Should the gui be removed or disabled (so one can see the used parameters, but does not get the impression to be able to edit and re-run them)?

I also:

1. Added a user preference to control the maximum number of concurrent

processes

2. Made XML validation error strings available as tab tool-tips
3. Updated doxygen.

Nice.

I did also make a minor change to the cli-module-support branch that will be
needed for the MITK branch to compile.

If the cli-module-support is merged to master again, and issue 236 merged to
master, then the MITK branch could be nearing completion.

What do you think?

Looks very promising to me! We should aim for early integration.

Also, feel free to update your MITK branch and see new screenshots.

Will do, thanks.

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(?).

(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(?).

Well spotted. Yes, the MITK plugin currently has effectively 2 browse buttons for each ctkPathLineEdit. I think we need the additional XSL file. Unless I have misunderstood something we need the QmitkDataStorageComboBox subclass for input images, but we need the ctkPathLineEdit for output. So we can't just use the QUiLoader.

Also, I noticed that the output filenames should be like a "Save As" box, where you select a directory and specify a filename, or select an existing file to replace. But I can't seem to do this with the ctkPathLineEdit. Is that right? Do we need a different widget?

(In reply to comment #78)

(In reply to comment #77)

Also, I noticed that the output filenames should be like a "Save As" box,
where you select a directory and specify a filename, or select an existing
file to replace. But I can't seem to do this with the ctkPathLineEdit. Is
that right? Do we need a different widget?

Hi there, it looks to me like in ctkCmdLineModuleXmlToQtUi.xsl we need to change

<property name="filters">
  <set>ctkPathLineEdit::Files</set>
</property>

to

<property name="filters">
  <set>ctkPathLineEdit::Files,ctkPathLineEdit::Writable</set>
</property>

for image, file and geometry widgets, and the same in the MITK plugin for QmitkDataStorageComboBox.xsl.

Does that look right?

Matt

OK, I just pushed to both branches.

https://github.com/commontk/CTK/commit/57baf3d33571d39871c7edcd622e0a8f8daaa3a4

and

https://github.com/MattClarkson/MITK/commit/f91344c3378a3e6273b6ba80d6d03a02a0cdbd07

to fix the issue you mentioned with the additional browse button.

Hi Sascha, I just pushed this:

https://github.com/commontk/CTK/commit/278240bbb607440eb02f35e72564be1046e47755

https://github.com/MattClarkson/MITK/commit/990e38b901dd880947b7925310304f6fbb31a4dc

to disable the parameters in the GUI that gets copied into the progress widget, to make it obvious that they should not be edited.

I thought it should go in the Qt bit in CTK, but it means another CTK update.

(In reply to comment #77)
Well spotted. Yes, the MITK plugin currently has effectively 2 browse
buttons for each ctkPathLineEdit. I think we need the additional XSL file.
Unless I have misunderstood something we need the QmitkDataStorageComboBox
subclass for input images, but we need the ctkPathLineEdit for output. So we
can't just use the QUiLoader.

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?

If I remember correctly, the XSL fragment in MITK was necessary because the original XSL did not distinguish between input and output types and also didn't allow to bind different property names for specific widgets.

See also http://www.commontk.org/docs/html/classctkCmdLineModuleFrontendQtGui.html

Also, I noticed that the output filenames should be like a "Save As" box,
where you select a directory and specify a filename, or select an existing
file to replace. But I can't seem to do this with the ctkPathLineEdit. Is
that right? Do we need a different widget?

Yeah, that would be nice. Maybe one could extend the ctkPathLineEdit widget with additional properties to further customize it... low priority?

(In reply to comment #81)

Hi Sascha, I just pushed this:

https://github.com/commontk/CTK/commit/
278240bbb607440eb02f35e72564be1046e47755

https://github.com/MattClarkson/MITK/commit/
990e38b901dd880947b7925310304f6fbb31a4dc

to disable the parameters in the GUI that gets copied into the progress
widget, to make it obvious that they should not be edited.

I thought it should go in the Qt bit in CTK, but it means another CTK update.

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?

Ah, I see. I just tried it. We can set the imageInputWidget to QmitkDataStorageComboBox and set its value with imageValueProperty, but then for output image types, the widget it still ctkPathLineEdit, and it doesn't have a "currentValue", so the value is not set. (actually, I just observed that the value was not set). So its almost like we need an "inputImageValueProperty", and "outputImageValueProperty", or we still need the XML?

(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.

or what about the bit of code I added only change input parameters? I have previously tried (a), and the whole gui is disabled, which doesn't help anyone. Or alternatively, the setParametersEnabled could be considered MITK specific functionality, as I want my progress widget to be fully disabled, and the widget is only ever used once. I could just move it down the class hierarchy.

(In reply to comment #85)

(In reply to comment #83)

(In reply to comment #81)

Or alternatively, the setParametersEnabled could be considered MITK
specific functionality, as I want my progress widget to be fully disabled,
and the widget is only ever used once. I could just move it down the class
hierarchy.

Ah, this might not work, as I wanted to use the ObjectTreeWalker.

(In reply to comment #84)

(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?

Ah, I see. I just tried it. We can set the imageInputWidget to
QmitkDataStorageComboBox and set its value with imageValueProperty, but then
for output image types, the widget it still ctkPathLineEdit, and it doesn't
have a "currentValue", so the value is not set. (actually, I just observed
that the value was not set). So its almost like we need an
"inputImageValueProperty", and "outputImageValueProperty", or we still need
the XML?

Oh yes, right. We should provide separate bindings for the value property for widgets where we distinguish between input and output types. Do you care to add that (also in the ctkCmdLineModuleFrontendQtGui documentation) or do you want me to do it?

(In reply to comment #86)

(In reply to comment #85)

(In reply to comment #83)

(In reply to comment #81)

Or alternatively, the setParametersEnabled could be considered MITK
specific functionality, as I want my progress widget to be fully disabled,
and the widget is only ever used once. I could just move it down the class
hierarchy.

Ah, this might not work, as I wanted to use the ObjectTreeWalker.

Hmm, yes. I think the functionality in the CTK class is a nice feature. Just disabling input widgets will leave out output parameters which are not "simple output parameters"... additionally, simple output parameters might no be disabled by default if someone overwrite the corresponding XSL variable.

I think (b) would be a clean way to do it, but (c) will work just as well.

Hi Sascha,

I just pushed https://github.com/commontk/CTK/commits/cli-module-support
(10 commits)

and also https://github.com/MattClarkson/MITK/commits/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

(4 commits).

I believe I have done option (b) providing a container widget for each group box, and providing ctkCmdLineModuleFrontendQtGui::setParameterContainerEnabled().

I also provided separate input/output bindings for the value property (and it looked to me like the geometry stuff was wrong anyway), and removed the redundant xsl file on the MITK side, and updated the ctkCmdLineModuleFrontendQtGui header file documentation.

Matt

[d4648b]: Merge branch 'bug-12506-update-ctk'

Merged commits:

2012-09-18 23:21:17 Sascha Zelzer [944693]
Use CTK with updated CLI support and fixed ctkPathLineEdit size hint.

Hi Sascha, please can you review the following:

https://github.com/commontk/CTK/commit/ca90678a93c512f2b87291e08fa9952a226888c0

it would need merging to master, and a new CTK version for apps such as MITK.
I only got to investigating it this morning.

Matt

Hi Sascha,

I pushed the following tweaks/bugfixes.

https://github.com/commontk/CTK/commit/ca90678a93c512f2b87291e08fa9952a226888c0

https://github.com/commontk/CTK/commit/0a669af19bf3ecc4173fcca69a9d833d49fce408

https://github.com/commontk/CTK/commit/6043315c618a0bbcf1663d79a7b8e3d32fbe0eb4

https://github.com/MattClarkson/MITK/commit/e65231800837b243b59cd6164e09404dcc4748be

the CTK ones are not yet merged to master. Do you want to check over them?

Matt

Hi Sascha,

thanks for spotting about the documentation in ctkCmdLineModuleFrontendQtGui.
It actually made me spot a mistake. I had generalised the setting of the parameter name, but not the setting of the value. So you could set a property called "filters", or "banana", but the values would always be ctkPathLineEdit::Files|ctkPathLineEdit::Readable which is a bit pointless if you have a different widget.

So I pushed:

https://github.com/commontk/CTK/commit/7112c047673004a5a2f7fa419d547b2965cbffd7

and

https://github.com/MattClarkson/MITK/commit/d80d6ad887cdbc3f5bc0d9364b11a0f9afc14787

I have not yet merged to CTK master, as I was thinking of doing some merging on Monday after your release today.

Matt

Hi there,

i just pushed:

https://github.com/MattClarkson/MITK/commit/d80d6ad887cdbc3f5bc0d9364b11a0f9afc14787

https://github.com/MattClarkson/MITK/commit/6dbfaf029d5c30a75c6c391cafb26eb5f9b80ad9

https://github.com/MattClarkson/MITK/commit/8279caac4aadabc2cfadff92bf70b069262e249d

https://github.com/MattClarkson/MITK/commit/aaa157de7f198a4ad3206b6abdf0fdc18b171f72

I have a query.

When there are a large number of generated widgets or a large number of running modules, the GUI expands, so that the main view has a scroll bar on the right, due to the main MITK view being contained within a QScrollArea.

Then its annoying in the current MITK CLI plugin if the user scrolls the mouse wheel, and parameter settings like QSpinBox or QDoubleSpinBox will scroll and change parameter values, when actually the user wanted to scroll the view up and down.

The same applies with the help and about box, as these are contained with QPlainTextEdit which also has its own scroll bars.

So, I tried changing the CTK xsl to put in a property to set QtFocusPolicy::StringFocus, but it didnt seem to work. Maybe I was setting it
on the wrong widget? Or maybe thats the wrong way?

Apart from that people are quite impressed with it, and its working nicely.

The other remaining issue is still that I can't always get std::cout output or fprintf(stdout), but I can get std::cerr and fprintf(stderr). Its not just NiftyReg. I made a script to run FSL's BET and it didn't work.... but the CTK test bed programs work????

Oh, and another thing ... is how to get the EXACT command line output dumped to console, as it would be useful for debugging. I was just thinking of a qDebug() in the ctkCmdLineModuleProcessTask::run.

Other than that :-) Nearly finished?

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.

so with BET you have to have

bet input.nii output.nii [options]

and this will fail

bet [options] input.nii output.nii

so I had to write a wrapper script to take the command line args generated by CTK, and re-order them. But is there a nicer way?

Matt

(In reply to comment #94)

Hi there,

i just pushed:

https://github.com/MattClarkson/MITK/commit/
d80d6ad887cdbc3f5bc0d9364b11a0f9afc14787

https://github.com/MattClarkson/MITK/commit/
6dbfaf029d5c30a75c6c391cafb26eb5f9b80ad9

https://github.com/MattClarkson/MITK/commit/
8279caac4aadabc2cfadff92bf70b069262e249d

https://github.com/MattClarkson/MITK/commit/
aaa157de7f198a4ad3206b6abdf0fdc18b171f72

These look all good (also the earlier CTK related ones). Thanks! Good spot for the default output file names.

I have a query.

When there are a large number of generated widgets or a large number of
running modules, the GUI expands, so that the main view has a scroll bar on
the right, due to the main MITK view being contained within a QScrollArea.

Then its annoying in the current MITK CLI plugin if the user scrolls the
mouse wheel, and parameter settings like QSpinBox or QDoubleSpinBox will
scroll and change parameter values, when actually the user wanted to scroll
the view up and down.

The same applies with the help and about box, as these are contained with
QPlainTextEdit which also has its own scroll bars.

I would have said that this is the usual and actually "expected" GUI behaviour :-) I know what you mean with "annoying" but I don't think we should try to change that. It really is how the GUI is supposed to work. The same behaviour is displayed in a web browser for example.

So, I tried changing the CTK xsl to put in a property to set
QtFocusPolicy::StringFocus, but it didnt seem to work. Maybe I was setting it
on the wrong widget? Or maybe thats the wrong way?

I have not much experience with Qt and focus policies but would have thought that is not a focus issue. Rather a responsibility issue for the mouse wheel event.

Apart from that people are quite impressed with it, and its working nicely.

That is nice to hear.

The other remaining issue is still that I can't always get std::cout output
or fprintf(stdout), but I can get std::cerr and fprintf(stderr). Its not
just NiftyReg. I made a script to run FSL's BET and it didn't work.... but
the CTK test bed programs work????

I have absolutely no idea what might be going on. If you have a small shell script or executable (or program code) with which one can reproduce this, I would be happy to have a look.

Oh, and another thing ... is how to get the EXACT command line output dumped
to console, as it would be useful for debugging. I was just thinking of a
qDebug() in the ctkCmdLineModuleProcessTask::run.

Sounds good to me.

Other than that :-) Nearly finished?

Yes! :-) Looks all very functional! We will very likely run into some bugs but it seems quite complete.

Ah, there are two pending features though. But I would suggest that we implement them "on demand".

1.) We do not yet support module logos. There is support for it specified in Slicer, but at a first look the image format seemed proprietary.

2.) We do not yet support saving/restoring different parameter sets for different modules. This is probably a MITK plug-in feature. Slicer provides this feature and when working regularly with cmd line modules, this is probably a "nice to have".

(In reply to comment #95)

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.

so with BET you have to have

bet input.nii output.nii [options]

and this will fail

bet [options] input.nii output.nii

so I had to write a wrapper script to take the command line args generated
by CTK, and re-order them. But is there a nicer way?

I can't think of one. We could blame the modules for their "primitive" command line argument parsing... we could also change the way how the arguments are assembled in ctkCmdLineModuleProcessTask such that indexed parameters appear first. This will probably break other moduels which expected them to appear after named/flagged parameters.

Personally, I don't have a preference.

We could also just use the order in the XML description when assembling the command line. Then we need to figure out what to do if the value of the "index" element of the parameter is not strictly increasing...

Hi there,

i pushed this:

https://github.com/commontk/CTK/commit/9c61f4649a349d9218bafa3176ec124c5d7667ee

and this:

https://github.com/commontk/CTK/commit/23352c2583e0e589b779147d1b1b78d421c82404

The first one was actually due to a bug on the master branch, so I merged straight away. The second was a qDebug statement as discussed, so I went ahead and merged that to master.

Following the conversation above:

1. I agree with your comments, and will leave the "focus" policy stuff i was saying about.
2. I think we should leave the argument ordering, as there is currently no clear solution...maybe discuss at a CTK hackfest if necessary. Different command line apps do different things. It may be better to stick to a clean spec, and let 3rd parties either write a wrapper script, or change their argument parsing.
3. The two features are nice, but as you say "on-demand", i.e. "if requested".

I agree on your points 2 and 3.

Looks like we can close this bug soon. Reaching comment #100 ... :-)

Ping me if you feel that the CTK master is ready to be included in MITK and I will update the hash value.

I win ... comment 100?

Checked in:
https://github.com/MattClarkson/MITK/commit/6bca0b2907b374aabbb5a6110ac6a2f7a06ad8b0

on branch:
https://github.com/MattClarkson/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

I think this is the bug with the most comments :-)

Merging the branch is on my list.

Please note, URL of repository has changed.

https://github.com/NifTK/MITK/tree/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

Hi Sascha,

I just committed this to the CTK/cli-module-support branch:
https://github.com/commontk/CTK/commit/48b7bd4e21f03d537ef75b0afc12ace6276e621e

and can now see output from NiftyReg programs in the console, and also the original ctkCmdLineModuleTestBed.

Please can you review?

Also, initial usage from our group suggests that the default paths we are providing in the MITK plugin are not very useful. The users just want to launch the app, and automatically have their modules available.

At the moment, there is no way of telling the ctkCmdLineModuleDefaultPathBuilder so independently provide paths for the ApplicationDir and ApplicationDir/cli-modules (or any such other string). So I was going to modify these methods a bit to enable independently picking subfolders under the application directory, the home directory, the current directory and the CTK_MODULE_LOAD_PATH.

Then the MITK plugin can be setup to always scan a sub-folder of the Application directory, without scanning the Application directory. This would be useful to us, as NifTK has at the last count about 99 command line apps, and about 50 scripts, and we dont want to check them all for XML. So, if we just deployed our CLI compatible programs and scripts to a sub-folder, we could scan it by default, and automatically pick up the installed CLI programs.

Well ... something like that anyway. So, if you have any suggestions, please send them my way.

Thanks

Matt

(In reply to comment #103)

Hi Sascha,

I just committed this to the CTK/cli-module-support branch:
https://github.com/commontk/CTK/commit/
48b7bd4e21f03d537ef75b0afc12ace6276e621e

and can now see output from NiftyReg programs in the console, and also the
original ctkCmdLineModuleTestBed.

Please can you review?

It took a while, but I wanted to understand why the original code failed. The QXmlStreamReader does not report character data until it reads the next start or ending tag. Since in your use case there never was such a tag, the character data was not reported. So your changes look good to me. Thanks.

Also, initial usage from our group suggests that the default paths we are
providing in the MITK plugin are not very useful. The users just want to
launch the app, and automatically have their modules available.

At the moment, there is no way of telling the
ctkCmdLineModuleDefaultPathBuilder so independently provide paths for the
ApplicationDir and ApplicationDir/cli-modules (or any such other string).
So I was going to modify these methods a bit to enable independently picking
subfolders under the application directory, the home directory, the current
directory and the CTK_MODULE_LOAD_PATH.

Sounds good.

Then the MITK plugin can be setup to always scan a sub-folder of the
Application directory, without scanning the Application directory. This
would be useful to us, as NifTK has at the last count about 99 command line
apps, and about 50 scripts, and we dont want to check them all for XML. So,
if we just deployed our CLI compatible programs and scripts to a sub-folder,
we could scan it by default, and automatically pick up the installed CLI
programs.

Well ... something like that anyway. So, if you have any suggestions,
please send them my way.

Sounds very reasonable to me. I also think that we would deploy command line modules in a specific sub-folder. Maybe even one sub-folder for each module in case that module has external library dependencies (to ITK for example) which can not be resolved against the MITK library dependencies.

Hi Sascha,

please can you sanity check the following stuff. I'm quite keen to merge today, so if you had 10 minutes for a look, I would be very appreciative.

Matt

I changed ctkCmdLineModuleDefaultPathBuilder to be able to have home directory, application directory, current working directory, and then any subfolder under these. To me it was a sort of Builder pattern, where you ask for lots of directory, then call getDirectoryList to get the output. This meant I could add a boolean controller "strict" mode where the builder would only return valid existing directories.

https://github.com/commontk/CTK/commit/0e55196c197a10c4ecd92cf373df338320d0b17e

I then changed ctkCmdLineModuleDefaultPathBuilder again so that you can just specify CTK_MODULE_LOAD_PATH as a series of colon, or semi-colon separated paths rather than just a single directory.

https://github.com/commontk/CTK/commit/94ddf92da13b406f342eb83ae8441d3e9fc47c84

I changed the unit test and doxygen, and it passed on Windows, Linux, Mac.

I then changed the MITK plugin to separate out the home directory, and the home-directory/cli-modules etc. to provide finer grained control.

https://github.com/NifTK/MITK/commit/8dd8d43d5993c1405de0a4b67d9977814e7cd7f3

and changed doxygen UserManual

https://github.com/NifTK/MITK/commit/3515f85c0e25b098f42add75e2930393c58146f2

where you can look at the diff of the png..basically more check-boxes.

Unfortunately, I didn't know of a better way than this:

https://github.com/commontk/CTK/commit/94ddf92da13b406f342eb83ae8441d3e9fc47c84#L0R125

i.e #ifdef Q_OS_WIN32

QString pathSeparator(";");

etc

What do you think? OK?

Matt

Everything looks very good to me. I don't know a "better" way for the path separator either...

I haven't looked at the default values for the path scanning options, but I assume there are some sensible presets, like scanning the cli-modules sub-folder in the installation directory by default.

+1 for the merge

CTK stuff merged to master

MITK stuff still on that branch, (and additionally merged into our niftk branches).

By default, the plugin searches in the cli-modules folder under where the application binary is.

Matt

Updating target milestone to upcoming release

Hi Sascha,

as discussed, I just pushed:
https://github.com/NifTK/MITK/commit/b1b62cc36e3f6c7c0e820816e4d27964357cba5f

to try and reject invalid file names when making the temporary files to save to.

I am also updating our niftk branch of MITK to get the latest fixes for the rendering of binary images, so will hopefully have that integrated into our overnight build today.

So, I can either sign off this 12506 branch today. Or we wait until tomorrow.

Also, in you email, you said I could add a new commit, and put the sign off message in there, and then publish the branch under a different name. But why would the branch need to be under a different name?

Thanks

Matt

(In reply to comment #109)

to try and reject invalid file names when making the temporary files to save
to.

Great!

I am also updating our niftk branch of MITK to get the latest fixes for the
rendering of binary images, so will hopefully have that integrated into our
overnight build today.

So, I can either sign off this 12506 branch today. Or we wait until tomorrow.

From my side, you could sign it off today. I don't think there will be any integration issues.

Also, in you email, you said I could add a new commit, and put the sign off
message in there, and then publish the branch under a different name. But
why would the branch need to be under a different name?

I couldn't find that mail right now... you are right, if you are adding a new commit, there is no need to use a new branch name. I was probably thinking that if you don't know of any changes warranting a new commit, you could rewrite the commit message of the last commit by adding the signed-off tag but would then have to use a new branch since you changed an already published commit... it's up to you ;-)

If you find the time today, I could probably also merge it to MITK today. Otherwise we will have to wait until next week.

Thanks a lot!

Hi Sascha,

I just pushed:
https://github.com/NifTK/MITK/commit/1a39700ff261516d4854fe6bf0db86ef1dddc93b

With reference to the notes you provided:
http://www.mitk.org/Sign_off_contribution

I am certifying clause (a).

Also, please note, that for this to compile a CTK upgrade is necessary. We have been using version dd4386a4b0, which is from Tue Nov 6 12:41:53. This is before the last CTK hackfest if I recall correctly, so I have not yet tested later versions, as I was waiting for the code to stabilise, and then I forgot about it.

A further note of interest is that by default the plugin is OFF in Plugins.cmake.

So, I have merged this latest version into branch nifty here:
https://github.com/NifTK/MITK/commit/c440edddb5419dd080c799ed74406d61c4c5fc63

which will then get rebuilt in our overnight process, if the change on the NifTK side is merged today... which it should be. We have been regularly using this on Windows, Linux, Mac since about November. So, all should be well.

What I plan to do then is to upgrade NifTK to use the March release of MITK (2013-03 I presume), as soon as it is available, and then we will be nicely synched up again.

Matt

[f46127]: Merge branch 'bug-12506-plugin-for-ctk-cli'

Merged commits:

2013-02-28 20:42:23 Sascha Zelzer [5d10ea]
Use new CTK for command line module support.

2013-02-28 20:17:07 Sascha Zelzer [2983d6]
Merge branch 'bug-12506-plugin-for-ctk-cli-orig' into bug-12506-plugin-for-ctk-cli

Conflicts:
Modules/Qmitk/QmitkDataStorageComboBox.h

Removed trailing whitespaces and new lines.

Reviewed-by: Sascha Zelzer <s.zelzer@dkfz-heidelberg.de>

2013-02-28 11:33:20 Matt Clarkson [1a3970]
Added one last author tag for doxygen.

Signed-off-by: Matt Clarkson <m.clarkson@ucl.ac.uk>

2013-02-28 09:41:33 Matt Clarkson [b1b62c]
Added GetValidNodeName to make sure node name only contains A-Z,a-z,0-9,period,hyphen and underscore as it is used to generate a file name

2012-11-06 13:40:00 Matt Clarkson [a0aa0a]
Command Line Modules View to scan bin/cli-modules by default

2012-11-06 08:17:29 MattClarkson [3515f8]
Updated UserManual for API change in ctkCmdLineModuleDefaultPathBuilder

2012-11-05 22:46:38 MattClarkson [1bc260]
Update CommandLineModulesView to match change in ctkCmdLineModuleDefaultPathBuilder API

2012-11-05 18:23:16 Matt Clarkson [8dd8d4]
Changed Pref Page to list mode options to scan, separating out home/application/current folders from the cli-modules sub-folders

2012-10-05 15:51:33 Matt Clarkson [686adf]
Renamed to org_mitk_gui_qt_cmdlinemodules and Command Line Modules View

2012-10-05 14:56:00 Matt Clarkson [f12dda]
Fix warning: extra tokens at end of #endif directive

2012-09-22 12:37:34 MattClarkson [aaa157]
Swap default output file names to be under default output directory, and check for running in application instance directory

2012-09-21 18:45:56 MattClarkson [8279ca]
Pass output directory name to CLI module progress widget

2012-09-21 18:43:35 MattClarkson [6dbfaf]
Added default output directory for CLI modules

2012-09-21 09:07:04 Matt Clarkson [d80d6a]
Updated QmitkCmdLineModuleGui to match CTK changes from imageInputFilterProperty to imageInputSetProperty

2012-09-20 05:54:06 MattClarkson [e65231]
Removed warnings about filters property not present in QmitkDataStorageComboBoxWithSelectNone

2012-09-16 02:16:35 MattClarkson [576f66]
Update CLI module to not need QmitkDataStorageComboBox.xsl on account of CTK updates

2012-09-15 22:51:36 MattClarkson [a8d30c]
Added call to setParameterContainerEnabled in reworked CTK ctkCmdLineModuleFrontendQtGui

2012-09-15 22:28:19 MattClarkson [fa0334]
Removed invalid setParametersEnabled as reworking CTK side

2012-09-15 22:24:00 MattClarkson [e5b628]
Removed redundant QmitkCmdLineModuleGui::lockGui()

2012-09-15 09:28:28 MattClarkson [990e38]
Set GUI parameters in progress widget to disabled in CLI module

2012-09-14 21:47:34 MattClarkson [f91344]
Remove addtional unnecessary browse button for image targets

2012-09-14 02:55:06 MattClarkson [8edf61]
Update doxygen for CLI module

2012-09-14 01:58:02 MattClarkson [2129a5]
Added XML validation errors as tab widget tool tips

2012-09-14 01:57:45 MattClarkson [17ea90]
Fixed typo in comment

2012-09-14 01:43:55 MattClarkson [1b3809]
Added user preference for max concurrent processes to CLI module

2012-09-14 01:07:26 MattClarkson [b26ee5]
Refactor CommandLineModulesView to enable multiple tabs, for multiple modules, and despatch multiple jobs

2012-09-14 01:06:47 MattClarkson [1329cf]
In QmitkDataStorageComboBoxWithSelectNone add SetSelectedNode and fix Q_PROPERTY definition

2012-09-13 01:49:14 MattClarkson [ac20fe]
Added ShowProgressBar and ShowConsole for CLI module

2012-09-13 01:38:45 MattClarkson [4f4516]
Reduced margins/spacing in QmitkCmdLineModuleProgressWidget

2012-09-13 01:32:07 MattClarkson [e5ca2b]
Convert generated Help and About tabs to ctkCollapsibleGroupBox for consistency in CLI module

2012-09-12 17:59:02 MattClarkson [62bf78]
Fix multiple layouts overlaying each other problem when switching CLI module

2012-09-12 17:30:23 MattClarkson [b7cf1d]
Improve minimum width: Remove choose label, and use tool tip instead

2012-09-12 14:02:50 MattClarkson [61a0d6]
Try grabbing all stderr and stdout output in CLI module

2012-09-12 14:01:26 MattClarkson [bd605c]
Added UCL credits to CLI module User Manual

2012-09-12 13:15:12 MattClarkson [0cae1f]
Fixed stdout and stderr reporting

2012-09-12 13:14:50 MattClarkson [04de0c]
Updated UserManual for CLI module to descript XML validation combo, and fix icon

2012-09-12 12:27:53 MattClarkson [b18c38]
Small layout changes in CLI module

2012-09-12 02:41:22 MattClarkson [99137f]
Fixed handling of URL in generated Help text for CLI module

2012-09-12 02:06:49 MattClarkson [41ea9a]
Added user preference for XML validation mode in CLI module

2012-09-12 01:24:41 MattClarkson [ddf638]
Tweaked status messages for cancelled CLI modules

2012-09-12 01:08:11 MattClarkson [806662]
Updated User Manual for CLI plugin

2012-09-11 23:40:51 MattClarkson [d37810]
Small cosmetic layout change, adding space in a QVBoxLayout

2012-09-11 23:39:17 MattClarkson [73ea0a]
Declared ctkCmdLineModuleReference as Qt MetaType to stop ctkMenuComboBox dropping entries

2012-09-11 22:55:42 MattClarkson [e52681]
Minor doxygen tweaks in CLI plugin

2012-09-11 22:55:15 MattClarkson [780be9]
Set object name on QAction in QmitkCmdLineModuleMenuComboBox

2012-09-11 22:54:26 MattClarkson [2f8d37]
Refactored CLI plugin to move logic out of CommandLineModulesView and into QmitkCmdLineModuleProgressWidget

2012-09-11 08:31:35 MattClarkson [f37446]
Changed layout of QmitkCmdLineModuleProgressWidget

2012-09-11 08:18:34 MattClarkson [be1474]
Moved processing logic out of CommandLineModulesView and into QmitkCmdLineModuleProgressWidget

2012-09-11 00:52:45 MattClarkson [4c8f0e]
Removed Stop button from the main view in CLI plugin

2012-09-11 00:49:17 MattClarkson [e31479]
Added QmitkCmdLineModuleProgressWidget based on ctkCmdLineModuleExplorerProgressWidget

2012-09-11 00:09:31 MattClarkson [9e3328]
Remove console from CLI plugin view

2012-09-10 23:30:07 MattClarkson [cdc98c]
Updated CLI view and preference page to handle individual modules

2012-09-02 22:51:10 MattClarkson [505f16]
Added connections to ctkCmdLineModuleFutureWatcher outputDataReady and errorDataReady

2012-09-02 22:50:27 MattClarkson [37c8c5]
Simplified preferences page, as file watching not ready yet

2012-09-02 22:35:16 MattClarkson [399cbb]
Removed spurious debug output from QmitkCmdLineModuleMenuComboBox

2012-09-02 22:09:29 MattClarkson [06d6be]
Removed ctkCmdLineModuleMenuFactoryQtGui and implemented ctkCmdLineModuleMenuComboBox

2012-08-31 09:23:12 MattClarkson [12be4d]
Updated CLI plugin to use ctkCmdLineModuleMenuFactoryQtGui from local folder, and compile ctkCmdLineModuleMenuComboBox

2012-08-31 09:22:45 MattClarkson [0afb61]
Moved ctkCmdLineModuleMenuFactoryQtGui from CTK to MITK

2012-08-31 09:22:22 MattClarkson [662e05]
Added new widget ctkCmdLineModuleMenuComboBox

2012-08-31 08:52:53 MattClarkson [94d5d9]
Added QmitkFileListWidget and QmitkDirectoryListWidget as helpers to set up preference page

2012-08-31 08:18:10 MattClarkson [f8352c]
QmitkUiLoader now derives from ctkCmdLineModuleQtUiLoader

2012-08-28 10:08:39 MattClarkson [f27e47]
Update CLI module to new CTK API including ctkPathListWidget

2012-08-24 21:42:17 MattClarkson [5ab8e2]
Added missing icon pause.png

2012-08-24 18:34:47 MattClarkson [c6cad8]
Added call to ctkCmdLineModuleFrontend::reset() to set parameters to defaults

2012-08-24 18:30:03 MattClarkson [b84835]
Tidy up debug/console output

2012-08-24 18:18:55 MattClarkson [836bc5]
Implemented pause, resume, cancel, stop, start in CLI module

2012-08-24 15:10:54 MattClarkson [b497ed]
In OnModuleFinished, now calling ClearUpTemporaryFiles

2012-08-24 15:09:16 MattClarkson [c0aca5]
Enabled correct selection of input/output images and hence first running version after Front End / Back End refactoring

2012-08-24 09:25:41 MattClarkson [bb14c2]
Stopped duplicate tabs being created

2012-08-24 09:11:19 MattClarkson [82bdeb]
Update to latest API after FrontEnd/BackEnd refactoring

2012-08-23 15:52:34 MattClarkson [f488f1]
Merge branch 'master' into MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

2012-08-23 07:19:51 MattClarkson [6b8f35]
Merge branch 'master' into MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

2012-08-20 08:41:34 MattClarkson [0a1541]
Remove references to QObject* currentObject in CommandLineModulesView

2012-08-16 13:57:30 MattClarkson [0caddc]
Provide subclass QmitkDataStorageComboBoxWithSelectNone to make sure we default to no selection in CLI module

2012-08-16 13:55:29 MattClarkson [222170]
Provide subclass QmitkDataStorageComboBoxWithSelectNone to make sure we default to no selection in CLI module

2012-08-16 10:40:44 MattClarkson [3a950f]
Set default temporary directory to that provided by QDir::tempPath in CLI module

2012-08-15 17:36:47 MattClarkson [a489c6]
Put help and about documentation on tab for each command line module

2012-08-15 15:50:57 MattClarkson [c96fc5]
Added user prefs to control ctkCmdLineModuleDefaultPathBuilder

2012-08-15 15:17:24 MattClarkson [cbbb50]
Added doxygen User Manual page for CLI view

2012-08-15 13:44:15 MattClarkson [8f0ce0]
Updated Help and About tabs in CLI module to display html

2012-08-15 13:15:03 MattClarkson [ebdddb]
Minimise #includes, fix mem leak, initialise m_ModuleFactory and m_DebugOutput

2012-08-15 13:02:09 MattClarkson [afa2b9]
Updates to method/class level doxygen

2012-08-15 12:32:08 MattClarkson [1f4e80]
First working version running NiftyReg (reg_aladin), and loading data back in when finished

2012-08-15 12:31:31 MattClarkson [9c4df1]
Change ExtApp to seed the random number generator from the current time

2012-08-14 15:23:18 MattClarkson [88a6b6]
Add missing file QmitkDataStorageComboBox.xsl

2012-08-14 14:53:35 MattClarkson [09c260]
Provide QmitkDataStorageComboBox just for input, and standard CTK ctkPathLineEdit for output

2012-08-14 11:25:12 MattClarkson [20d225]
Provide xsl override to replace ctkPathLineEdit with QmitkDataStorageComboBox in CLI plugin

2012-08-14 09:34:37 MattClarkson [0cd73c]
Updated copyright in .cpp files in CLI plugin

2012-08-13 22:40:55 MattClarkson [f40711]
Updated class documentation and copyright info

2012-08-13 17:40:39 MattClarkson [d9da52]
Using QmitkDataStorageComboBox in CLI module, for referring to images

2012-08-13 17:38:59 MattClarkson [590d38]
Minor formatting changes

2012-08-13 17:38:16 MattClarkson [3f75d3]
New classes QmitkCmdLineModuleGui, QmitkCmdLineModuleFactoryGui

2012-08-13 15:06:05 MattClarkson [0ce3de]
Added new class QmitkUiLoader in CLI plugin

2012-07-20 00:42:31 MattClarkson [cea4e8]
Switch from MattClarkson/CTK/matt-cli-module-support to CTK/cli-module-support and change *ModuleInstance to *Module

2012-07-19 07:45:26 MattClarkson [dd3f9e]
CommandLineModulesView connect to ctkCmdLineModuleManager moduleAdded, moduleRemoved instead of ctkCmdLineModuleDirectoryWatcher

2012-07-18 13:46:29 MattClarkson [0d6a57]
Moved directory scanning logic, and QMenu building code to ctkCmdLineModuleDirectoryWatcher and ctkCmdLineModuleMenuFactoryQtGui

2012-07-14 03:17:57 MattClarkson [afa930]
removed #include <ctkCmdLineModuleProcessFuture.h>

2012-07-14 03:06:54 MattClarkson [216523]
CLI plugin: merged changes from origin/MITK-bug-12506-trac-1588-MITK-plugin-for-CTK-CLI

2012-07-14 02:56:46 MattClarkson [33ebb9]
CLI plugin: Update to latest API

2012-07-12 18:05:02 MattClarkson [e65f15]
CLI plugin: Add checkbox for debug output on CLI view preference page

2012-07-12 14:43:07 MattClarkson [1edb4e]
CLI plugin: provide default and user-pref directories to scan

2012-07-12 11:48:43 MattClarkson [8f16b8]
CLI plugin: remove connection to non-existing slot onPathsUpdated

2012-07-12 11:42:19 MattClarkson [ebeea6]
CLI plugin: MITK preference page with module paths

2012-07-12 11:41:54 MattClarkson [3ca08e]
CLI plugin: added undo icon

2012-07-11 17:39:38 MattClarkson [a5de50]
CLI plugin: loading module names from hard coded directory

2012-07-11 17:38:57 MattClarkson [f6b4ad]
CLI plugin: reworked controls

2012-07-11 17:38:37 MattClarkson [a0888d]
CLI plugin: added undo icon

2012-07-11 10:37:59 MattClarkson [859c26]
CLI plugin: Set icons using CommandLineModulesViewControls, basic run process

2012-07-11 09:34:42 MattClarkson [8f5a82]
CLI plugin: New Qt class CommandLineModulesViewControls

2012-07-12 18:05:02 MattClarkson [4cd1d7]
CLI: Add checkbox for debug output on CLI view preference page

2012-07-12 14:43:07 MattClarkson [fb9b28]
CLI: provide default and user-pref directories to scan

2012-07-12 11:48:43 MattClarkson [8e71f4]
CLI: remove connection to non-existing slot onPathsUpdated

2012-07-12 11:42:19 MattClarkson [8179d7]
CLI: MITK preference page with module paths

2012-07-12 11:41:54 MattClarkson [b3736c]
CLI: added undo icon

2012-07-11 17:39:38 MattClarkson [126285]
CLI plugin: loading module names from hard coded directory

2012-07-11 17:38:57 MattClarkson [bf935f]
CLI plugi: reworked controls

2012-07-11 17:38:37 MattClarkson [c3cf71]
CLI plugin: added undo icon

2012-07-11 10:37:59 MattClarkson [e74d23]
CLI: Set icons using CommandLineModulesViewControls, basic run process

2012-07-11 09:34:42 MattClarkson [a13e0a]
CLI: New Qt class CommandLineModulesViewControls

2012-07-10 18:32:13 MattClarkson [b2cee2]
CLI plugin: added new files, icons, resources

2012-07-10 18:13:10 MattClarkson [870ef1]
CLI plugin: fix to new Api

2012-07-10 17:55:42 MattClarkson [c31a94]
CLI plugin: checkin before Sascha refactoring

2012-07-10 14:30:57 MattClarkson [2d3d61]
CLI plugin: set directory correctly

2012-07-10 13:56:53 MattClarkson [c82a27]
New plugin for Command Line Interface (CLI)

New remote branch pushed: bug-12506-plugin-for-ctk-cli

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.

(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.

You are very welcome.

Im going to check my oloh stats on Monday :-)