Hi Miklos, we totally agree that we need to fix some stuff to make all of this more generic.
Looking at all occurrences of the string "stdmulti." revealed that most of the time it could be easily replaced with something more generic, as it is just used to get *any* slice navigation controller or similar. Same for occurrences of GetQmitkRenderWindow. Two examples where something more sophisticated is happening are segmentation (i.e. the "apply interpolation for" button), and the movie maker. Both cases should be not too hard to be replaced with more generic code. However you can have multiple editors/render parts open and visible at the same time, though. Hence, we believe that we need a more general solution than querying the active render window part, whatever that would mean in such a scenario. In most use cases one would simply want to query all visible render windows, no matter in which render window part they are embedded, instead of all render windows of a certain render window part. That said, wouldn't it make sense to begin with improving the ID stuff in a sense of removing all of the stdmulti.widget semantic/special handling? We also could imagine a micro service approach for all of this querying stuff including render window parts to make it accessible from everywhere. Best, Stefan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Miklos Espak Sent: Donnerstag, 23. Februar 2017 11:44 To: Dinkelacker, Stefan Cc: mitk-users Subject: Re: [mitk-users] *Modules* without multi widget and global rendering manager instance 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
