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

Reply via email to