Hi,

I would like to discuss a problem with a customized BlueBerry-workbench 
application that I recently came across. My questions are: considering below's 
story,

1. is my fix reasonable, i.e. should it be integrated into MITK? Or is this 
unwanted usage of the multi-widget editor plugin?

2. do you see a better option to "configure" multi-widget editor during startup?


Any comments are appreciated.


In our specific implementation of berry::WorkbenchWindowAdvisor we sucessfully 
do a couple of modifications to the workbench's appearance. Now I want to adapt 
the multi-widget's crosshair visibility default from the window advisor. Adding 
a plugin depencency towards

org.mitk.gui.qt.stdmultiwidgeteditor, looking up the correct editor, and doing 
my customization works fine.


However, org.mitk.gui.qt.stdmultiwidgeteditor depends on 
org.mitk.gui.qt.common, which is now loaded very early, at a point in time when 
workbench ist not yet running. Unfortunately, the workbench being running is an 
implicit requirement of org.mitk.gui.qt.common. When the workbench is not yet 
running during plugin activation, org.mitk.gui.qt.common will not initialize 
its QmitkViewCoordinator and attempt to work an a nullptr when the plugin 
finally is unloaded. I fixed this using the attached patch. It seems to work 
fine, I just wonder whether I'm getting myself into future problems due to this 
dependency.


Kind regards,

Daniel


--

Dr. Daniel Maleike, Mint Medical GmbH

Friedrich-Ebert-Straße 2, 69221 Dossenheim/Heidelberg
Geschäftsführer: Dr. Matthias Baumhauer, Registergericht Mannheim, HRB 709351

Attachment: fix-view-coordinator-init.patch
Description: fix-view-coordinator-init.patch

------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users

Reply via email to