Hi Stefan, Michael,
I don't really have an opinion on the subject at hand because I know
almost nothing about blueberry.
My suggestion is simply : if you keep the code this way, can you please
always call SetDataManager()? It will make your code an epsilon less
complicated and your users' code a lot less complicated.
In all cases, we did it in our in-house version of MITK. It would be
simpler for us (and maybe for other) if it was already in MITK.
Nil
Le 2016-04-04 05:05, Müller, Michael a écrit :
Hi Nil, Stefan,
Well, I disagree to what you said Stefan and I suppose to leave it how
it is implemented. We had some hard discussions about how “dynamic”
the whole DataManager monster should be. The key point is – surprise,
surprise - that other views may add context menu action to the
DataManager without any dependency. As a central view within a highly
dynamic application framework this makes sense.
I agree that there are much lines of BlueBerry code needed making some
files or sections hard to read. And I agree that the DataManager
monster class has grown to Godzilla in the meantime. Maybe introducing
some shortcut code for Blueberry and some refactoring and care for the
DataManager is the alternative to going back to good old monolithic times.
Bye
Michael
*Von:*Kislinskiy, Stefan [mailto:s.kislins...@dkfz-heidelberg.de]
*Gesendet:* Montag, 4. April 2016 10:34
*An:* Nil Goyette <nil.goye...@imeka.ca>; mitk-users@lists.sourceforge.net
*Betreff:* Re: [mitk-users] SetDataStorage in QmitkDataManagerView.cpp
Hi Nil,
as far as I know, the context menu entries of the Data Manager were
never fully implemented in BlueBerry. Well, to be honest, they might
have been implemented since the last BlueBerry update a year ago but
you probably know more than me when you are fiddling around with them
at the moment. :-) However, I know that there are (were?) historic,
ugly, hard-coded workarounds for certain data types in the Data
Manager, sorry. In the BlueBerry/OSGI/Eclipse world, this is supposed
to be loosely coupled and dynamic. If it isn’t in MITK (which I
guess), that would be a nice mini project. You could help us by filing
a feature request in our bug tracker for your needs/thoughts and
setting its target milestone to AfterNextRelease, in order to have a
realistic chance of having these features implemented in the release
after next.
Best regards,
Stefan
*From:*Nil Goyette [mailto:nil.goye...@imeka.ca]
*Sent:* Freitag, 1. April 2016 17:38
*To:* mitk-users@lists.sourceforge.net
<mailto:mitk-users@lists.sourceforge.net>
*Subject:* [mitk-users] SetDataStorage in QmitkDataManagerView.cpp
Hi MITK,
I was creating a context menu action and I saw that SetDataStorage was
never called. I found in QmitkDataManagerView.cpp this snippet:
if(className == "QmitkCreatePolygonModelAction")
{
contextMenuAction->*SetDataStorage*(this->GetDataStorage());
if(smoothed == "false")
{
contextMenuAction->SetSmoothed(false);
}
else
{
contextMenuAction->SetSmoothed(true);
}
contextMenuAction->SetDecimated(m_SurfaceDecimation);
}
else if(className == "QmitkStatisticsAction")
{
contextMenuAction->SetFunctionality(this);
}
else if(className == "QmitkCreateSimulationAction")
{
contextMenuAction->*SetDataStorage*(this->GetDataStorage());
}
I don't understand this decision. Why not simply always set it? I know
that Smoothed, Decimated and Functionality are hacks useful only to a
single class, but DataStorage is useful in many cases. Well, I don't
know for the other programmers out there, but I often need the
DataStorage in my context menu actions.
Right now, I'm forced to use my plugin's context, getServiceReference,
IDataStorageService and include a lot of files to get it. This could
easily be avoided if SetDataStorage was always called. I just tried it
and it works perfectly. In fact, I don't see how it could break anything.
Nil
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
