Hi Stefan, sure, thank you very much.
I tend to think that the easiest solution would be a utility class in MitkCore with a static function that can return the active render window part of the active application instance. That would give access to the render windows and the rendering manager as well. And you would not need to pass down render window part pointers from the plugin level. Best, Miklos On 23 February 2017 at 10:05, Dinkelacker, Stefan <[email protected]> wrote: > Hi Miklos, > > we see the issues. We'd like to discuss all of this in our next internal MITK > meeting, which would be on Tuesday afternoon. Is it okay for you to wait a > few days? :-) > > Best, > Stefan > > -----Original Message----- > From: Miklos Espak [mailto:[email protected]] > Sent: Donnerstag, 23. Februar 2017 10:32 > To: mitk-users > Subject: [mitk-users] *Modules* without multi widget and global rendering > manager instance > > 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 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging tech > sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mitk-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mitk-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
