Port the previous 3D Connexion Mouse support from QT3 to QT4 application. Redesign the way how to add external devices such as the 3D connexion mouse or WiiRemote to MITK applications.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Restricted Maniphest Task | ||||
| Wontfix | • fetzer | T6685 Port and redesign 3D Connexion Mouse support for linux | ||
| Resolved | None | T4965 Port and redesign 3D Connexion Mouse support |
Event Timeline
Comment Actions
(I'm resetting the core modification flag because no wiki page is linked and no references to core modifications are made in the description)
Comment Actions
(In reply to comment #1)
(I'm resetting the core modification flag because no wiki page is linked and no
references to core modifications are made in the description)
That's because I was about to write it a little later and didn't expect a response this fast. I'm requesting it again.
Comment Actions
In an earlier version of the MITK with QT3, code was developed to integrate a 3D Connexion mouse (modelname: Space Navigator). This input device should provide a possibility to navigate in a 3D space without using keyboard and a normal mouse simultaneously. Unfortunately the design of the integration wasn't modular. Therefore it was mandatory to design a new pattern, which allows on the one hand to easily integrate new input devices and on the other hand to be as modular as possible.
The idea for the integration is using extension points, bundles and modules in combination. Extension points are defined in XML schemes (plugin.xml) and used to load the classes each input device needs after the associated device is activated in the preferences of the GUI. The bundle in between acts as the extension point, which links the application to the proper module. It usually contains an activator class with the necessary register methods for listeners and the event mapper addons. The classes themselves such as the addons, the driver and the controller are stored in the module.
After the activation of a new input device, the self implemented or manufactured driver wants to communicate with the software every time its status changes. On a status change of the device, the driver executes the action and forwards it to the appropiate addon. There a suitable event is created and fired to the global eventhandler. It will be compared with all registered events and forwarded to its listener. Reaching the controller it will trigger an action, for example a mouse movement on the display.
Comment Actions
could you please use the MITK_INFO , etc. macros instead of std::cout, e.g. in AddEventMapperAddOn().
Comment Actions
[SVN revision 25473]
COMP (#4965): removed ascii symbol in scope of eventmapper method
Comment Actions
[SVN revision 25477]
COMP (#4965): fixed problem with const iterator and the method erase from vector
Comment Actions
[SVN revision 25492]
COMP (#4965): removed TDxInput.tlh,because does not work and deactivated both bundles
Comment Actions
[SVN revision 25525]
FIX (#4965): spacenavigator on default excluded; module classes are loaded individually depending on flags
Comment Actions
[SVN revision 25527]
COMP (#4965): fixed linker problem by manually adding a linker language
Comment Actions
[SVN revision 25544]
FIX (#4965): space navigator bundle removed from exclude list and fixed space navigator driver
Comment Actions
[SVN revision 25545]
COMP (#4965): only windows compatible - bundles and module will only be built in windows