>
> I am not really opposed to the workbench listener approach, I just don't
> think it is needed.
>
I would be happy with another solution that works, just do not see any.
> 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?
>
It's not the question if the workbench is running. It *is* running when the
activator is started, berry::Platform::IsWorkbenchRunning() returns true.
But the workbench has not started up fully, the PostStartup function of the
workbench has not been invoked yet, the views are not opened, their plugins
might not even be loaded yet.
I can put some processing in the dnd display plugin. I do not think that
the constructor of the editor would be a good place though, as you can
close the editor and open a new one, but the CL args should be processed
only once. I can of course introduce static flags to check if it is the
first run but that would be really ugly.
Moreover, I do not know where to process the --perspective option. This
option assumes that the plugins that provide the required views are already
loaded. Otherwise, you can see an exception in the view instead of the
actual GUI controls.
> 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.
>
This might work, I'll try this.
Thanks,
Miklos
>
> 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]>
> 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
>
>
------------------------------------------------------------------------------
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
