Matt is right. I know that plugin well, and I these are actual problems. Currently, the only way for getting around this problem is to hide the level window widget or the whole QmitkStdMultiWidget (because it is not in synchron with the actual level window values) and now also to reimplement the whole topmost image selection in the view.
The QmitkLevelWindowWidget and QmitkSliderLevelWindowWidget classes have other bugs and missing features as well that prevents me of using it. You find some problems here: https://github.com/cim-unito/MITK/issues?sort=created&direction=desc&state=closed&page=1 (I closed them as WONTFIX, they are not solved.) I thought about sharing the level/window manager between the level window widget and Matt's lookup table plugin, but it is not possible for two reasons. First, the widget does not provide a public accessor to get it. At second, even if it was accessible, the editor can be closed and reopened any time, and the manager does not survive this. So, either a central lookup table manager should be used from the plugins (provided by a micro service?) but then it should be thread safe. Or, any number of managers should work independently. Thanks, Miklos On Wed, Jan 18, 2012 at 1:04 PM, Clarkson, Matt <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ 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
