Hi Florian, a common solution in MITK for using a data storage in a module is to provide setters for the data storage in according classes, so one can pass a pointer to the data storage from a plugin to a class that is located in a module. Even very central data storage oriented GUI classes like QmitkDataStorageComboBox works like this. Which leads to the next point, separation of classes for modules and plugins. You can even move most of your GUI classes to a module, so in a very clean example, a plugin would contain only the necessary classes to wire up all the module stuff with the BlueBerry stuff that is declared in your plugin.xml. Unfortunately we have many counterexamples in MITK. :-)
BTW a common strategy in MITK seems to be to have separate modules for non-GUI stuff and GUI-stuff, so you can still user your algorithms in non-Qt-applications for example. Best, Stefan -----Original Message----- From: Florian Jung [mailto:florian.j...@igd.fraunhofer.de] Sent: Dienstag, 12. Juli 2016 10:10 To: Kislinskiy, Stefan; mitk-users@lists.sourceforge.net >> mitk-users Subject: Re: [mitk-users] Problem with new datainteractor concept in plugin Hi Stefan, thank you very much for the quick response. I see a lot of refactoring coming up for us :D We still do not completely understand the design. The next problem which will occur for us is, that if we migrate the plugin to a module is, that we will not be able to access the datastorage from within the module anymore, which will break some other stuff. We'll have to see how we will handle this. What confuses us a bit. The state machines are stored in the module. But the loading of the state machines is triggered by the plugins anyway. Is there a benefit of moving the core to a module. Because this results in overhead for every plugin, if this seperation was not done from the start? So the general idea is, to always have a module and a plugin for a addon and seperate? Core/Algorithms -> module View/UI -> plugin Best regards Florian Am 11.07.2016 um 09:48 schrieb Kislinskiy, Stefan: > Hi Florian, > > AFAIK we do not have an example of interactors in MITK that are > located in a plugin. Hence, the quickest solution, and probably also a > more clean one from a software architecture perspective, is to move > your interactors to a module, possibly together with other classes > that are not required to be located in a plugin. :) > > Best, > Stefan > ________________________________________ > Von: Florian Jung [florian.j...@igd.fraunhofer.de] > Gesendet: Montag, 11. Juli 2016 09:35 > An: mitk-users@lists.sourceforge.net >> mitk-users > Betreff: [mitk-users] Problem with new datainteractor concept in > plugin > > We wanted to migrate our plugins to the new datainteractor concept. > Unfortunately we weren't successful yet. > > Our problem is, that our own state machines are never found. > As we understood, the modulecontext has to be passed along to the loader. > > SnippeBBut We tried several things from > http://docs.mitk.org/2015.05/Step10Page.html > It seems that the state machines are usually saved as a compressed zip > file. But the zip file which should be created containing the > statemachine files is never created and consequently the state > machines are not found during runtime. > > Could someone help us out, how it is intended to be done if you have a > plugin, not a module? > > Best regards > Florian > > -- > Florian Jung > Department Visual Healthcare Technologies > > Fraunhofer-Institute for Computer Graphics Research IGD Fraunhoferstr. > 5, 64283 Darmstadt, Germany > > phone: +49.6151.155.520 > fax: +49.6151.155.480 > email: florian.j...@igd.fraunhofer.de > web: http://www.igd.fraunhofer.de > > > ---------------------------------------------------------------------- > -------- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T > Park in San Francisco, CA to explore cutting-edge tech and listen to > tech luminaries present their vision of the future. This family event > has something for everyone, including kids. Get more information and > register today. > http://sdm.link/attshape > _______________________________________________ > mitk-users mailing list > mitk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mitk-users -- Florian Jung Department Visual Healthcare Technologies Fraunhofer-Institute for Computer Graphics Research IGD Fraunhoferstr. 5, 64283 Darmstadt, Germany phone: +49.6151.155.520 fax: +49.6151.155.480 email: florian.j...@igd.fraunhofer.de web: http://www.igd.fraunhofer.de ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
