https://github.com/MITK/MITK/pull/136

I do not know if there is already a convention about how to name this kind of flags. Feel free to change the name. I mean if you consider to merge this at all. :-)

Would you mind describing that workaround? That way we could point future users to it, if they have the same issue.

I had to introduce some command line options, e.g. for opening images with a given data node name, or setting properties of the images (e.g. level-window) or define source node-derived node relationships for the images to open.

You can define new options if you derive a class from mitk::BaseApplication and override the 'defineOptions()' function. You can bind the arguments to names, and then they will be put in the framework context, and you can access them from the plugin context. E.g. I have a '--perspective <perspective name>' option that I bound to a name, and I could access it as a property of the plugin context. It's gonna be a QVariant that stores a QString.

Any command line argument that matches a defined option will be processed and removed from the argument list, berry::Platform::GetApplicationArgs(). The activator of the org.mitk.gui.qt.ext plugin goes through these arguments and tries to open each of them as an image file or MITK scene.

So far so good.

My problem was that I could not define every supported option in this way. You can mark options as 'repeatable', but if you bind name to a repeatable option, the plugin property will contain a QString with the value for the last occurence of the option on the command line, and not a QStringList with every value.

E.g. with this command:

NiftyView --open T1:image.nii.gz --open mask:segmentation.nii.gz

the context will store only "mask:segmentation.nii" and not a string list with both values.

Since I did not see a solution for this, I did not define this option, but then the arguments were kept in berry::Platform::GetApplicationArgs(), and I had to pick them out from there, so I needed to suppress the argument processing in org.mitk.gui.qt.ext and do the processing myself.

The solution was this little function in my application class:

void BaseApplication::HandleRepeatableOption(const std::string& name, const std::string& value)
 {
   QString propertyName = "applicationArgs.";
   propertyName.append(QString::fromStdString(name));
 
   QStringList valueList = this->getProperty(propertyName).toStringList();
   valueList.append(QString::fromStdString(value));
   this->setProperty(propertyName, QVariant::fromValue(valueList));
 }

And then instead of using the bind function, I could use this handler:

Poco::Util::Option openOption("open", "o", "opens a file with the given name");
 openOption.argument("<name>:<file>").repeatable(true);
 openOption.callback(Poco::Util::OptionCallback<BaseApplication>(this, &BaseApplication::HandleRepeatableOption));
 options.addOption(openOption);

And then from the plugin activator I could access the '--open' option arguments in a QStringList (in a QVariant), from the 'applicationArgs.open' context property.

So, at the end, I could define every option through Poco, nothing was left mixed with the image file names on the path, so I could just let org.mitk.gui.qt.ext to process them, as it would do.

Thanks for the detailed walkthrough!