Hi Christian,
meanwhile I moved the code to a module, and could load event configurations
from xml resources. Loading the config from a stream input allows more
flexibility and I might need this feature again at some point. So, thank
you for this.
What regards the legacy display interaction handling in the ToolManager,
the workaround I found was to duplicate the mitk::DisplayInteractor in our
codebase with a different class name that is *not* derived from
mitk::DisplayInteractor, otherwise its event config would have been
overloaded in the ToolManager. So removing the legacy display interactor
handling from the ToolManager is really useful for me, since I can make my
display interactor derive from the original, and can get rid of most of the
duplicated code.
Thank you for all this. I will test the change early next week.
Regards,
Miklos
On Thu, Apr 18, 2013 at 9:01 AM, Weber, Christian(1) <
[email protected]> wrote:
> Hi Miklos,****
>
> ** **
>
> sorry for the late reply. The 1 represents the core module , so
> ActivateTool uses this to access the resources in the Core.****
>
> In your case using the resources via micro services to load resources of a
> plugin isn’t possible since plugins don’t have a module context****
>
> (you can however access the resources of other modules, like the core
> module, as in your example).****
>
> I just fixed bug 14915, to provide a module independent way of creating
> event configurations,****
>
> (http://bugs.mitk.org/show_bug.cgi?id=14915 )****
>
> which will enable you to change the configuration by supplying a ifstream
> to the configuration file.****
>
> Also in this branch the legacy handling is removed from the ToolManager as
> this seems to make things only more complicated for you.****
>
> If you like you can check out the branch to see if this solves the
> problems for you, it will probably be merged into the master in the next
> weeks after it has been tested a bit more.****
>
> ** **
>
> Code to replace the Interaction from a plugin could look like this:****
>
> // Construction providing a input stream****
>
> std::ifstream* configStream = new std::ifstream( #path to
> configuration file# );****
>
> mitk::EventConfig newConfig(configStream);****
>
> ** **
>
> std::list<mitk::ServiceReference> listEventObserver =
> GetModuleContext()->GetServiceReferences<InteractionEventObserver>();****
>
> for (std::list<mitk::ServiceReference>::iterator it =
> listEventObserver.begin(); it != listEventObserver.end(); ++it)****
>
> {****
>
> DisplayInteractor* displayInteractor =
> dynamic_cast<DisplayInteractor*>(****
>
> GetModuleContext()->GetService<InteractionEventObserver>(*it));****
>
> if (displayInteractor != NULL)****
>
> {****
>
> displayInteractor->SetEventConfig(newConfig);****
>
> }****
>
> }****
>
> ** **
>
> ** **
>
> Regards****
>
> Christian****
>
> ** **
>
> ** **
>
> *Von:* Miklos Espak [mailto:[email protected]]
> *Gesendet:* Mittwoch, 3. April 2013 13:15
> *An:* Weber, Christian(1)
>
> *Betreff:* Re: [mitk-users] GlobalInteraction::INFORM_ONE****
>
> ** **
>
> Hi Christian,****
>
> ** **
>
> my ActivateTool calls are in plugins, not in modules. How can I access the
> module context from there?****
>
> ** **
>
> I have seen this at some places in the MITK source:****
>
> mitk::ModuleContext* moduleContext =
> mitk::ModuleRegistry::GetModule(1)->GetModuleContext();****
>
> Is this correct? What is that 1?****
>
> Thank you,****
>
> Miklos****
>
> ** **
>
> On Wed, Apr 3, 2013 at 12:01 PM, Weber, Christian(1) <
> [email protected]> wrote:****
>
> Hi Miklos,****
>
> ****
>
> sorry, I think I missed your whole point in the beginning. If you want to
> change it without touching any code from the master,****
>
> you can use the code you provided (*) . The place to put it is, _*after
> your*_ ActivateTool(..) call, else it’ll be immediately overwritten, as
> this function now contains the legacy handling. ****
>
> ****
>
> Regards****
>
> Christian****
>
> --****
>
> Please note that function for loading the config file has been renamed to:
> ****
>
> SetEventConfig****
>
> ****
>
> *Von:* Miklos Espak [mailto:[email protected]]
> *Gesendet:* Sonntag, 31. März 2013 17:41
> *An:* Weber, Christian(1)****
>
>
> *Cc:* mitk-users
> *Betreff:* Re: [mitk-users] GlobalInteraction::INFORM_ONE****
>
> ****
>
> Hi Christian,****
>
> ****
>
> I have tried, but I could not change the display interaction configuration
> from our application. I added the code to the Activated and Deactivated
> function of our tool. Although it loaded my configuration, in one of the
> two cases (don't remember if it was the activation or deactivation) it was
> then overwritten by the mitk::ToolManager::ActivateTool() function.****
>
> ****
>
> In my point, the interaction configuration xml file in MITK is also MITK
> source code, since I can change it in our MITK fork, not in our app. We
> would like to diverge from the upstream as little as possible.****
>
> ****
>
> I meant the RESOURCE_FILES section of the files.cmake, which are not Qt
> resources.****
>
> ****
>
> I'm not sure what would be the ideal solution for this problem.****
>
> ****
>
> Regards,****
>
> Miklos****
>
> ****
>
> ****
>
> On Sun, Mar 31, 2013 at 3:32 PM, Weber, Christian(1) <
> [email protected]> wrote:****
>
> Hi Miklos,
>
> yes, this would work. But you can modify the one in the resources, as this
> file was introduced to allow you to modify the behavior without chaning the
> source code.
> But your version works as well.
> Just as a note, I'm unsure what you mean by Qt resources, to include the
> OurCustomDisplayConfigMITKTools.xml you have to add it winthin the
> files.cmake into the very last section.
>
> Regards,
> Christian
> ________________________________________
> From: Miklos Espak [[email protected]]
> Sent: Thursday, March 28, 2013 11:52 PM
> To: Weber, Christian(1)
> Cc: mitk-users
> Subject: Re: [mitk-users] GlobalInteraction::INFORM_ONE****
>
>
> Thank you so much Christian, this works very well!
>
> Am I right that if I want to disable the middle button move with the tools
> through the MITK API instead of modifying the xml in the MITK sources, then
> I have to put the following code fragment after (or instead) setting the
> notification policy to INFORM_ONE?
>
> std::list<mitk::ServiceReference> listEventObserver;
> ServiceTracker<InteractionEventObserver*>* eventObserverTracker=
> new ServiceTracker<InteractionEventObserver*>(GetModuleContext());
> eventObserverTracker->Open();
> eventObserverTracker->GetServiceReferences(listEventObserver);
> for (std::list<mitk::ServiceReference>::iterator it =
> listEventObserver.begin(); it != listEventObserver.end(); ++it)
> {
> InteractionEventObserver* interactionEventObserver =
> eventObserverTracker->GetService(*it);
> if (interactionEventObserver != NULL) {
> DisplayInteractor* displayInteractor =
> dynamic_cast<DisplayInteractor*>(interactionEventObserver);
> if (displayInteractor != NULL) {
> // here the regular configuration is loaded again
>
> displayInteractor->LoadEventConfig("OurCustomDisplayConfigMITKTools.xml","Mitk");
> }
> }
> }
> eventObserverTracker->Close();
> delete eventObserverTracker;
>
>
> ... and add our custom display config to the Qt resources?
>
> Thanks,
> Miklos****
>
> ****
>
> ** **
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
