Hello,
I've made great progress following your advice. Although, I will say that
the Wiki on Modules is not detailed enough. It didn't discuss some extra
CMake options needed to have MITK's build system store the interactor XML
files (e.g. RESOURCE_FILES). Poking around other modules definitely helped
me figure out what was missing.
The Plugins section is more thoroughly documented but didn't mention that
files like interactor XML configurations could only be retrieved from a
Module. Well, the mitk::DataInteractor API deceptively tells you that
arguments are filenames anyway. Interactors are also very well documented
in the MITK wiki, although I seem to remember Wiki discussions on the topic
broken up into 3 separate pages making a bit difficult to follow.
Lastly, I found that the QtWidgetsExt actually has an interactor
(mitkAffineBaseDataInteractor3D) for things like boxes (mitk::Cuboid). It
wasn't being activated because QmitkBoundingObjectWidget was trying to load
AffineConfig.xml. However, the authors seem to have split up the event
configurations into a keyboard and mouse-specific configuration which I
think is very nice! Changing QmitkBoundingObjectWidget to load
AffineMouseConfig.xml did the trick. My problem is now 75% solved thanks to
your awesome toolkit.
All I need to do now is implement some missing functionality like scaling
(already done) and some way to deform the objects. Then I need to add the
ability to save objects.
I've been learning MITK over the span of 2-3 days and I have to tell you
the way mitkAffineBaseDataInteractor3D is implemented is completely
different than how I thought I should implement my BoxInteractor. I'm
confused about its use of geometry, the meaning of "timeSteps" and time
(undo/redo?), storing anchor point information as DataNode properties
instead of in the geometry? I also didn't know about some details like
using the InteractionEvent to grab the sender's rendering manager to update
everything.
Again, thanks for your help. I will probably use MITK for more than just
annotating in the future. This has been a great learning experience.
Best regards,
Nathan Lay
On Tue, Apr 11, 2017 at 5:07 AM, Dinkelacker, Stefan <
s.dinkelac...@dkfz-heidelberg.de> wrote:
> Yes, but it’s not only for the interactor resources. Splitting your code
> into a module and a plugin is a good design decision in general
> (reusability and so on, you name it). Unfortunately we have lots of
> anti-examples in MITK, but ideally you would place as much as possible in
> modules (even GUI stuff) and keep the plugins as minimal as possible, i.e.,
> they are just the “run-time dynamic interface” with the BlueBerry framework.
>
>
>
> Best,
> Stefan
>
>
>
> *From:* Nathan Lay [mailto:ens...@gmail.com]
> *Sent:* Dienstag, 11. April 2017 00:39
> *To:* Dinkelacker, Stefan
> *Subject:* Re: [mitk-users] How to load StateMachine and Config?
>
>
>
> Hi Stefan,
>
> Thanks for the prompt response. So does that mean that I need to create a
> module just so my plugin can load its interactor XML files from a Module?
>
> I just want to make a plugin. I don't want to make a module. But the
> source code says that the XML files for interactors are loaded via Modules.
>
> Best regards,
>
> Nathan Lay
>
>
>
> On Mon, Apr 10, 2017 at 5:51 PM, Dinkelacker, Stefan <s.dinkelacker@dkfz-
> heidelberg.de> wrote:
>
> Hi Nathan,
>
>
> it seems like you're confusing modules with plugins. See the simulation
> module and plugin for a working example. The XML files are located in the
> *module* (see [1]). The interactor is created in the
> org.mitk.gui.qt.simulation *plugin* though, by loading the resources from
> the simulation module (see [2]).
>
>
> GetModuleContext() is intended for modules.
>
>
> Best,
> Stefan
>
>
> [1] https://github.com/MITK/MITK/blob/master/Modules/
> Simulation/files.cmake#L27-L30
>
> [2] https://github.com/MITK/MITK/blob/master/Plugins/org.mitk.
> gui.qt.simulation/src/internal/QmitkSimulationView.cpp#L44-L53
>
>
> ________________________________
> Von: Nathan Lay <ens...@gmail.com>
> Gesendet: Montag, 10. April 2017 22:37
> An: mitk-users@lists.sourceforge.net
> Betreff: [mitk-users] How to load StateMachine and Config?
>
>
> Hello list,
> I'm having trouble convincing MITK to load the StateMachine and Config XML
> files owing to what appears to be issues with pulling resources from
> Modules.
>
> I get this error in particular: "Resource not valid. State machine pattern
> not found:BoxInteractions.xml"
>
> I've read the 2-3 different Wiki articles from the MITK Wiki covering
> interactors. None of them describes anything having to do with Modules and
> never mentions that MITK treats the XML file names as keys to some resource
> backend. I haven't been able to find how to package my interactor XML files
> into a Module and looking at other plugins with interactors doesn't seem to
> reveal anything terribly obvious. I see that the echotrack plugin uses a
> module named MitkUS and multilabelsegmentation uses
> us::GetModuleContext()->GetModule()
> to load its interactor XML files. The default behavior of these loading
> functions seem to use GetModuleContext().
>
> All I know is that us::GetModuleContext() returns NULL for my module. I
> thought it was because of my chosen name is org.mitk.boxannotator ... so I
> re-made the plugin and named it org.mitk.core.boxannotator. No luck there.
> And it doesn't work when trying to pass one of the various modules stored
> in us::ModuleRegistry (e.g. MitkCore, CppMicroServices, etc... names that
> don't seem to be listed anywhere on the wiki).
>
> I wish I could just change StateMachineContainer::LoadBehavior to
> fallback to simple std::fstream but with MITK having its own special stream
> class ModuleResourceStream and something called ModuleResource, it's not
> obvious to me how to do this.
>
> Any ideas?
>
> I really appreciate the extensive documentation of MITK on the Wiki and it
> seems to be one of the few extensible platforms with an acceptably fast
> DICOM image loader. No offense to Slicer3D, but it's very slow with loading
> DICOMs! ITK-SNAP seems to be the fastest, but it is not extensible (not
> visibly documented anyway). But I do currently feel that some aspects of
> MITK are overdesigned. This may be a newbie's impression, but I have to say
> that I feel very cheated when I try to tell my interactor to load some XML
> files by file name (or even absolute path) only to find that it doesn't
> work because MITK is trying to do something clever with some kind of Module
> resource backend.
>
> Also, I see that there is a QmitkBoundingObjectWidget. I would very much
> like to re-use this widget for placing and modifying bounding cuboids
> (since it already lets you place them), but it doesn't seem to want you to
> inherit it and it's not obvious to me how to attach an interactor to the
> BoundingObjects it places so that I can do things like resize or move them.
> Is there any hope here or am I better off just ignoring this widget and
> sticking with interactors? I'm currently (trying) sticking a
> BoundingObjectGroup into DataStorage with my interactor attached to its
> DataNode.
>
> Best regards,
> Nathan Lay
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
