Hi Matt, I just pushed some changes made by Daniel and Markus to the bug branch 10371 which originally caused your problems.
http://mitk.org/git/?p=MITK.git;a=shortlog;h=refs/heads/bug-10371-new-mouse-modes Perhaps you can merge it with your current version and check if the issues are solved now. Regards, Alex On Thu, 2012-01-19 at 08:52 +0100, Clarkson, Matt wrote: > Hi there, > > an alternative solution.... if indeed the future of Level / Window management > is to have a single one, is to move the mitkLevelWindowManager out of > QmitkLevelWindowWidget, and make it an accessible member of the > mitkDataStorage class? So it's obvious that there should be only one...... > (well.... can we assume that there should be only one DataStorage?).... and > then the QmitkLevelWindowWidget could simply look up the data storage and get > access to the LevelWindowManager? > > As it stands though, the current status does not work for me at all. I have > had to put a hack in to force m_AutoTopMostImage to true, or else I can't > adjust the window/level of my images. > > This is quite an urgent problem for me, so I will help resolve it if we come > up with a plan. > > Thanks > > Matt > > > On 18 Jan 2012, at 14:03, Miklos Espak wrote: > > > 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 ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
