That works for me. In the long term, it may be better to decide if we only want one global mitkLevelWindowManager, but I believe this change is sufficient for now. Thanks M
On 9 Feb 2012, at 15:57, Alexander Seitel wrote: > 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
