Standalone igtl Client

[christiana]

I have been considering how to extract a full standalone igtl Client from the OpenIGTLinkIF repo, as discussed in Boston (http://wiki.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/TrackedUltrasoundStandardization).

For testing and possibly for use in applications, we would like the GUI from OpenIGTLink as Slicer-independent code. There should also be possible to reuse more basic parts of the library, either the full Client (no GUI), or only the converter classes. Suggested dependencies below:

All the Slicer-independent code could ultimately be included in the OpenIGTLink repo itself, every module as a conditional build.

The Client itself can be separated from Slicer like shown in the diagram:

The main idea is to remove the inheritance from MRMLNode ( currently Connector, Converterts and Devices all are MRMLNodes), and instead use aggregation, i.e. Slicer will listen to the Client and create MRMLNodes wrapping the igtl devices/connectors as needed. The Converters could be an implementation detail hidden from external users. The Manager would contain much of the code currently present in vtkSlicerOpenIGTLinkIFLogic. A data layer duplicating some of MRML's features would have to be implemented (i.e. the Nodes), but this can be made as simple as possible, with no persistence (for now).

I am very interested in comments to this proposal, in particular:

• Do this (first) design outlined look sound, what can be improved?
• Who is interested in the resulting code, and at what level?
• Can the result eventually be merged back into Slicer? This determines whether or not we should refactor the Slicer binding layer or simply extract the code of interest.

[adamrankin]

Thank you very much for putting this effort into the IF layer. Is this something we would like to meet about virtually and discuss?

[drouin-simon]

I fully agree with the overall architecture that you propose in the first diagram. I would suggest we focus on the lower levels first (the client and the converters) and then, once its working, we can start talking about the interface and see if we can all agree on a single one for all our apps.

About the way you separate Slicer code and standalone client code, this is more or less the structure I had in mind, but I find the Node class on the non-mrml side complicates things. I think most applications that want nothing to do with Slicer or MRML won't care that device and connection derive from the same class. Specialized nodes on the MRML side can have Connection and Device aggregates. But maybe I didn't understand what you were trying to do... we could a have a quick google hangout (say we limit it to 30 min) to discuss this.

[christiana]

@drouin-simon: The node actually was a way to ease the connection to Slicer, I see that now. The adaption should be on the other (Slicer) side.

[christiana]

I suggest we have a Google Hangout tomorrow January 20. at 20:00UTC (21:00 Norway, 15:00 Boston/Montreal). I'll post the link here.

[adamrankin]

Is there any chance it could be moved + or - one hour?

[christiana]

+1 hour is OK for me, i.e January 20. at 21:00UTC (22:00 Norway, 16:00 Boston/Montreal). Is that ok for all?

[adamrankin]

That would be great, thanks!

[drouin-simon]

Works for me.

[lassoan]

I'm available tomorrow any time before 15:45 (or after 5pm). I like Christian's proposal and agree with Simon's comments, so I'm quite sure that the discussions will go in the right directions even without me - no need to reschedule the meeting just because of my availability.

[christiana]

Ok, we'll stick with the current time. Great that you follow the discussion, Andras.

[christiana]

New structure. All work is done within each device, except for creation. The converters are used privately by devices.

One missing piece is the querying mechanism from Slicer, i.e. for GET_, STT, and getting replies. I cannot find any example of usage for this. In the above design all messages related to one device, also queries, should be handled by that device.

[christiana]

https://hangouts.google.com/call/etb6mvdshlhiiyuix6bcwu3b3aa

[adamrankin]

https://hangouts.google.com/call/h3pryazesc4jecb5ccmeupddpua

On Wed, Jan 20, 2016 at 3:05 PM, Christian Askeland <
notifications@github.com> wrote:

New structure. All work is done within each device, except for creation.
The converters are used privately by devices.

[image: igtlclient_uml]
https://cloud.githubusercontent.com/assets/436646/12461354/bf6d7378-bfb8-11e5-9ac0-e81d82a2ba73.png

One missing piece is the querying mechanism from Slicer, i.e. for GET_,
STT, and getting replies. I cannot find any example of usage for this. In
the above design all messages related to one device, also queries, should
be handled by that device.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[christiana]

What are the opinions on Qt dependency? Are there some kind of policy that says Qt should only be in the GUI?

There is some kind of separation in OpenIGTLinkIF: The Logic is QT-independent, while the module and gui are Qt-dependent. This causes some strange tricks to appear, like having a QTimer in the qSlicerOpenIGTLinkIFModule that calls into vtkSlicerOpenIGTLinkIFLogic, thus breaking encapsulation.

IF we chose to use Qt also in the backend, i.e. in the client, that would simplify the code a lot.

In CustusX we use Qt on all levels, btw.

[lassoan]

Qt is a huge dependency, much more difficult to accommodate than VTK:

1. VTK is often used with .Net GUI, more and more on mobile devices, etc. This would be much more difficult with Qt.
2. Recent free Qt versions are LGPLv3, which prevent using of the toolkit in locked-down devices (where the user cannot replace a library), such as in most medical devices. VTK is BSD license.
3. It's nice to be able to create a small VTK client without a GUI or with a single VTK render window. Qt code base is 10x or so larger, takes more time to build, etc.

So, yes, I would avoid using Qt in the logic.