Hi,
I am not really opposed to the workbench listener approach, I just don't
think it is needed.
Although your activator might be called before the workbench is running,
the constructor of our custom editor certainly isn't. Can't you do the
processing there?
Another but more sophisticated approach would be to use the config admin
ctk plug-in. You would do your processing in the workbench advisor class
and set "configuration" objects via the config admin service. Your other
plug-in can then listen for specific config objects and (re)configure
itself accordingly.
Cheers,
Sascha
On 09/02/2015 01:32 PM, Miklos Espak wrote:
I would like to do that. The problem is that if I put the code in the
activator of the dnddisplay plugin, it runs too early, and the
workbench has not started up yet. I have to schedule it to run after
the workbench has started. I could solve this with a workbench
listener if it had a PostStartup function. Actually, the patch I wrote
looks working well to me.
On 1 September 2015 at 17:42, Sascha Zelzer <[email protected]
<mailto:[email protected]>> wrote:
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
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
