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]> 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]> 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
>> [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
