Hi Benjamin,
there is no generic messaging component in MITK (yet). But depending on
your requirements, you have quite a few options.
If you don't want to introduce dependencies between your plugins, you
could do one of the following:
- Use QEvent objects as you suggested. You could create one plugin
which declares a QEvent subclass (or multiple) which can be used by all
other plugins to send/receive your custom events.
- Use a similar approach as above, but with mitk::Message. Create a
separate plugin containing a "message broker", which manages one or more
mitk::Message instances to which consumers can subscribe. This avoids
the direct coupling between your plugins.
The key in both scenarios for a generic messaging system (in my opinion)
is to use a map (std::map, QHash, etc) containing the message
parameters. Don't try to use a lot of QEvent subclasses or many
mitk::Message[1|2|3|4] instances with different template parameters
(unless your set of events don't need to be extendible by plugins).
To make the classes from your "messaging plugin" available, just add the
following line to the META-INF/MANIFEST.MF file of your plugins:
Require-Bundle: <your-messaging-plugin-symbolic-name>
You could also use MITK_CREATE_MODULE, to create a "normal" shared
library. Then add the dependency to it in your plugins CMakeLists.txt
file by adding the module name as an argument to the
MACRO_CREATE_MITK_PLUGIN() macro call (see any of the existing MITK
bundles).
Of course you can always introduce direct dependencies (by using the
"Require-Bundle" header in the MANIFEST.MF file) between your plugins
and call methods on their public API. Just cast the result of
this->GetSite()->GetPage()->FindView("name.of.the.plugin")
to the correct type, or use other methods (for example use services and
the service registry) to access instances from other plugins.
Best,
Sascha
On 12/02/2010 05:38 PM, Benjamin Knecht wrote:
> Dear all,
>
> I work on a project where we use MITK and write our own plugins. Now
> the plugins work pretty well independently, but to improve our
> workflow we want to communicate between the plugins. We managed to get
> a reference to another plugin using
>
> this->GetSite()->GetPage()->FindView("name.of.the.plugin");
>
> Now we want to send messages. Using the message framework from MITK
> seems to require the sender to know the class of the receiver, which
> is not possible or useful with plugins. Another idea was to use our
> own events inheriting from QEvent, but we have no idea how to include
> them as a dependencies in CMake for our plugins. Could we use the
> MITK_CREATE_MODULE macro or is there a better way to make certain
> classes available to all plugins?
>
> cheers, Benjamin
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
