Hi Miklos,
this all makes sense. Why can't you just process the cmd args specific
to your DnDDisplay in the very same plug-in the DnDDisplay is defined?
Cheers,
Sascha
On 08/28/2015 07:45 PM, Miklos Espak wrote:
Hi Sascha,
yes, I tried the WorkbenchAdvisor::PostStartup. Actually, all the CL
argument processing was done in that function before the MITK upgrade,
but now I had to move it somewhere else. The problem is that the
workbench advisor is defined in the application plugin, i.e. the one
that provides the org.blueberry.osgi.applications extension point and
that is kicked off by mitk::BaseApplication.
However, I found that this plugin must not depend on plugins that
provide a view that derives from QmitkAbstractView. This class is
defined in org.mitk.gui.qt.common. Otherwise, the
org.mitk.gui.qt.common would be loaded together with the application
plugin because of the transitive dependency. This is a problem because
the activator of org.mitk.gui.qt.common assumes that the workbench is
already running:
https://github.com/MITK/MITK/blob/master/Plugins/org.mitk.gui.qt.common/src/internal/QmitkCommonActivator.cpp#L47
What is obviously not the case when the application plugin is just
being loaded.
This also causes a crash when shutting down the application because
the view coordinator is NULL here:
https://github.com/MITK/MITK/blob/master/Plugins/org.mitk.gui.qt.common/src/internal/QmitkCommonActivator.cpp#L63
So, the application plugin must not depend on e.g. our DnDDisplay
plugin that gives our custom editor. So, I cannot process the command
line args there which would manipulate the DnD display. So, I have to
move the CL arg processing to a different plugin, and somehow schedule
it to the time when the workbench has started.
Does this make sense?
Cheers,
Miklos
On 28 August 2015 at 18:01, Sascha Zelzer <[email protected]
<mailto:[email protected]>> wrote:
Hi Miklos,
command line arguments are added as plugin framework properties
and can be queried by any plug-in by calling
ctkPluginContext::getProperty(...).
For post workbench startup actions, the berry::WorkbenchAdvisor
class is intended to provide this facility. Did you run into
problems with that one?
Best,
Sascha
On 08/27/2015 10:18 PM, Miklos Espak wrote:
Hi,
I introduced some command line arguments for our MITK based
application, e.g. --perspective, to set the initial perspective,
and others to set the initial layout of our custom editor. Until
the MITK upgrade the arguments were processed in the PostStartup
function of our Workbench class that was in our application
plugin. Now I have to move the code to a different plugin so that
the application plugin does not have a transitive dependency on
org.mitk.gui.qt.common. (This plugin assumes that the workbench
is ready when it gets activated.)
What I figured so far:
Now you need to override the defineOptions function of your
application class. My looks like this now:
void defineOptions(Poco::Util::OptionSet& options) override
{
Poco::Util::Option perspectiveOption("perspective", "", "name of
initial perspective");
perspectiveOption.argument("<perspective>").binding("niftk.perspective");
options.addOption(perspectiveOption);
mitk::BaseApplication::defineOptions(options);
}
And I try to access the "niftk.perspective" configuration
parameter from the activator of a plugin, like this:
Poco::Util::LayeredConfiguration& config =
Poco::Util::Application::instance().config();
if (config.has("niftk.perspective"))
{
....
}
But this config object does not have that configuration property.
There used to be a berry::Platform::GetConfiguration() function
(you can still find some uses in the MITK sources) but it has
been removed.
Any idea, how to access those properties? Should that function be
reintroduced?
My other problem is that it does not seem to be possible to run
code after the workbench has started. There is an
IWorkbenchListener class, but it only has PreShutDown and
PostShutDown functions but no PostStartUp. I noticed that when
the plugin activator above runs,
berry::PlatformUI::IsWorkbenchRunning() returns true but the
PostStartUp function of the workbench has not run yet.
Should berry::IWorkbenchListener have a PostStartUp function?
Cheers,
Miklos
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected] <mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users