Miklos Espak
2017-02-23 09:32:20 UTC
Hi,
TLDR;
I will send a few big PRs for some old, not functional sort of bugs,
but there are further problems that need some design changes that I'd
like to discuss.
We have a custom editor. Let's call it "DnD display" (as drag&drop).
And we also use QmitkStdMultiWidgetEditor. Let's call it "MITK
display".
We want to make our DnD display work with every MITK view and want to
make our views work with both displays.
Awful lot of work has been done in the past to allow decoupling views
from the multi widget. (Mostly because of us, as I know, so thank you
again.) There is a guide about how to do that:
http://www.mitk.org/wiki/ViewsWithoutMultiWidget
However, there are still views in MITK that are written in the 'old
way', and I also discovered some problems that the current design does
not handle.
First, about the views written in the old way. The old
QmitkFunctionality class has been moved to
org.mitk.gui.qt.common.legacy, and this 'legacy' plugin has been
marked as deprecated. This was many years ago, so it would be high
time to convert the remaining views and say good bye to the legacy
plugin for good. I migrated most of the code but not all. I will send
them as separate PRs, but we are still on 2015.05.2, so first I will
need to rebase, that will bring up tons of conflicts and so on.
Second, about the things that are not covered by the migration guide.
1.) Referring to the multi widget renderer names directly.
E.g.:
const QString renderWindowName =
QString("stdmulti.widget%1").arg(renderWindow + 1);
vtkRenderWindow* theRenderWindow =
mitk::BaseRenderer::GetRenderWindowByName(renderWindowName.toStdString());
This is a problem because the name of a renderer cannot be changed
after construction, and they have to be unique. So, if I want to allow
both displays in the same app, I have to call the renderers of the DnD
display differently, not "stdmulti.widget[1234]". Hence, this code
will never return a DnD display render window. But it won't work even
with only the DnD display because it can contain multiple 2x2 multi
widgets, but this code could only retrieve a render window from its
first multi widget.
This sort of code is usually either in widgets (not views /
functionalities) that do not have a reference to a render window part,
or they are in a module. mitk::IRenderWindowPart is defined in a
plugin (org.mitk.gui.common), and it cannot be accessed from modules
at all.
One solution could be to pull up the interfaces from
org.mitk.gui.common to the module level, e.g. MitkCore, and to push
down references of render window parts to the objects in the modules.
E.g. QmitkToolSelectionBox (in MitkSegmentationUi) could have a
SetRenderWindowPart function that would be called from the
segmentation plugin so that QmitkToolSelectionBox can get a reference
to the *currently selected* axial window instead of retrieving
"stdmulti.widget1" always.
Or, there could be a static function to get the currently selected
render window part.
2.) Using the global rendering manager instance to request updates.
If multiple editors are allowed in the same app, it is better if each
has their own rendering manager. First of all, only one can be seen at
a time, so there is no point to update the windows of the hidden one.
Second, you might want to initialise the two displays through their
rendering manager with different geometries. E.g. the MITK display
likes a 'global reinit' after nodes are added, but the DnD display
likes the geometry to be fixed to a certain image. (You drag&drop the
image on the window.)
However, if the displays have their own rendering manager, you should
always update the windows of the rendering manager of the currently
selected render window part, *not* the global rendering manager.
The solution could be similar as for 1.).
Can we discuss a solution for 1) and 2) ?
What would be the best way?
Thanks so much,
Miklos
TLDR;
I will send a few big PRs for some old, not functional sort of bugs,
but there are further problems that need some design changes that I'd
like to discuss.
We have a custom editor. Let's call it "DnD display" (as drag&drop).
And we also use QmitkStdMultiWidgetEditor. Let's call it "MITK
display".
We want to make our DnD display work with every MITK view and want to
make our views work with both displays.
Awful lot of work has been done in the past to allow decoupling views
from the multi widget. (Mostly because of us, as I know, so thank you
again.) There is a guide about how to do that:
http://www.mitk.org/wiki/ViewsWithoutMultiWidget
However, there are still views in MITK that are written in the 'old
way', and I also discovered some problems that the current design does
not handle.
First, about the views written in the old way. The old
QmitkFunctionality class has been moved to
org.mitk.gui.qt.common.legacy, and this 'legacy' plugin has been
marked as deprecated. This was many years ago, so it would be high
time to convert the remaining views and say good bye to the legacy
plugin for good. I migrated most of the code but not all. I will send
them as separate PRs, but we are still on 2015.05.2, so first I will
need to rebase, that will bring up tons of conflicts and so on.
Second, about the things that are not covered by the migration guide.
1.) Referring to the multi widget renderer names directly.
E.g.:
const QString renderWindowName =
QString("stdmulti.widget%1").arg(renderWindow + 1);
vtkRenderWindow* theRenderWindow =
mitk::BaseRenderer::GetRenderWindowByName(renderWindowName.toStdString());
This is a problem because the name of a renderer cannot be changed
after construction, and they have to be unique. So, if I want to allow
both displays in the same app, I have to call the renderers of the DnD
display differently, not "stdmulti.widget[1234]". Hence, this code
will never return a DnD display render window. But it won't work even
with only the DnD display because it can contain multiple 2x2 multi
widgets, but this code could only retrieve a render window from its
first multi widget.
This sort of code is usually either in widgets (not views /
functionalities) that do not have a reference to a render window part,
or they are in a module. mitk::IRenderWindowPart is defined in a
plugin (org.mitk.gui.common), and it cannot be accessed from modules
at all.
One solution could be to pull up the interfaces from
org.mitk.gui.common to the module level, e.g. MitkCore, and to push
down references of render window parts to the objects in the modules.
E.g. QmitkToolSelectionBox (in MitkSegmentationUi) could have a
SetRenderWindowPart function that would be called from the
segmentation plugin so that QmitkToolSelectionBox can get a reference
to the *currently selected* axial window instead of retrieving
"stdmulti.widget1" always.
Or, there could be a static function to get the currently selected
render window part.
2.) Using the global rendering manager instance to request updates.
If multiple editors are allowed in the same app, it is better if each
has their own rendering manager. First of all, only one can be seen at
a time, so there is no point to update the windows of the hidden one.
Second, you might want to initialise the two displays through their
rendering manager with different geometries. E.g. the MITK display
likes a 'global reinit' after nodes are added, but the DnD display
likes the geometry to be fixed to a certain image. (You drag&drop the
image on the window.)
However, if the displays have their own rendering manager, you should
always update the windows of the rendering manager of the currently
selected render window part, *not* the global rendering manager.
The solution could be similar as for 1.).
Can we discuss a solution for 1) and 2) ?
What would be the best way?
Thanks so much,
Miklos