Hi there, The use case is that we have our own plugin that manages a host of lookup tables and has sliders for min, max, window and level. I could easily just update a nodes Level/Window, but to do that I would have to write the same logic to look up the first image, or the selected image, or the top most image. mitkLevelWindowManager does this for us, so we re-used it.
By setting the imageForLevelWindow property, two completely independent LevelWindowManagers are no longer independent due to the property causing m_AutoTopMostImage to change. This is analagous to having a class member variable updated by two threads when the variable should be method local. In addition, we have our own editor. So, the user is not even looking at QmitkStdMultiWidgetEditor, and so the QmitkLevelWindowWidget is not visible. But my lookup table plugin with min, max, window and level sliders is visible. I use two perspectives, one to give the standard MITK layout showing the image navigator, and the QmitkStdMultiWidgetEditor, and one to show my editor, and my other plugins. So, we should not assume that the GUI only has 1 perspective, with 1 editor and hence that the QmitkLevelWindowWidget is visible, as other applications might prefer different layouts. Further problems exist due to the fact that many plugins are derived from QmitkFunctionality which forces an incorrect dependency on QmitkStdMultiWidget being visible. This has the side effect that very often, this editor is brought to the front (obscuring my editor) when it isn't needed. For example you load a new image, and the editors swap place (???). In addition when a nodes Level/Window is updated, the QmitkLevelWindowWidget does not update.... it should probably listen to the property change, and not assume that the only way of editing the property is via itself. Some suggestions could include: 1. The mitkLevelWindowManager should register to property change events of the current image so it updates itself. 2. It should be possible to have 2 mitkLevelWindowManagers, as they may be more than one plugin or editor with different controls on for this purpose. 3. QmitkFunctionality should be refactored, so that code to do stuff like look up data storage, and preference managers is in a different class, and code that really needs access to QmitkStdMultiWidget is separate. Hopefully this makes sense. Does all this help? Thanks Matt On 18 Jan 2012, at 08:49, Markus Engel wrote: > Hi Matt, > > it is true that we assign a bool property to the one image for which we want > to modify the level/window. > However, as far as I know, this property is only evaluated by the > mitkDisplayVectorInteractorLevelWindow that is only used in the > new interaction mode of the ExtApp. > If you do not want to use this interactor (strictly speaking it's a listener > by the way) the behaviour should not have changed. > > As for your problem, I cannot think of a use-case right now for which you > would need two LevelWindowManagers. > If you could explain your plans I should be able to be of more assistance. > > Greets, > Markus > > > -------- Original Message -------- > Subject: [mitk-users] Recent changes to mitkLevelWindow Manager > Date: Tue, 17 Jan 2012 15:58:44 +0100 > From: Clarkson, Matt <[email protected]> > To: [email protected] <[email protected]> > > Hi there, > > please can someone help me understand these changes: > > http://mitk.org/git/?p=MITK.git;a=commitdiff;h=05141565fbe7df618626569d0af54a616e0c025a > http://mitk.org/git/?p=MITK.git;a=commitdiff;h=86687c4d22e86c213334f36c1ad553159254b343 > > The reason I ask is that I have my own plugin to manage lookup tables, and I > instantiate an mitkLevelWindowManager and connect it to the data storage. > Previously, it was the top most visible node that was considered the selected > node, so that changes to the level/window applied to that node. > This appears to have changed. These two diffs shown above introduced a new > property imageForLevelWindow on the actual data node, and then this appears > to cause the mitkLevelWindowManager::m_AutoTopMostImage in my > LookupTableManager (not the one created in DataStrorage) to revert to being > false which changes the expected behaviour. > > In other words (by which I implicitly mean "as far as I understand it"), the > fact that we are storing a property on a data node, stops you from using two > Level Window managers, as the property is shared via the DataStorage. This > appears to be either a wrong design, or something I have misunderstood. > Please can someone take a look? > > Thanks > > Matt > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers is > just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro > Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > mitk-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mitk-users > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
