CamiTK extensions

CamiTK extensions basically are plugins that can be developed and added to your project.

This page explains the different aspects of this concept.

Why developing with CamiTK means building extension?

CamiTK does not want you to modify any of your own code. Your code is your specialty, and you are the only one to know what is best to do there. Instead CamiTK asks you to provide a glue to the service layer: you need to encapsulate your work in a pre-define extension type. This generally means a minimal or no modification of your own code. There is no modification needed if you already have a well defined API where the GUI is completely separated from the rest. This is generally the case if you have followed well known/recommended software design. If not, your code can only gain extensibility, maintainability, and more generally quality, from the new design!

An extension in CamiTK is distributed as a plugin. There are four types of possible plugins in the CamiTK architecture (see below).

Building an extension is easy and is simplified by using the available wizard application which generates the code skeleton and configuration file. Once an extension is build and ready, it can be automatically integrated with all the existing extension, i.e., once ready you can start using your extension immediately.

The learning curve for CamiTK is meant to be minimal.

Extension types

What are the four types of extensions?

There are four types of extensions:

• Component extensions, they provide data I/O features,
• Action extensions, they provide data processing features,
• Viewer extensions, they provide interaction and visualization features, and
• MainWindow extensions, they provide a way to design a GUI main window by compositing viewers.

The service layer contains all the code that binds them together. It is a very important (and rather complex) concept, but hopefully you won’t have to dig into it to develop your own project.

These extensions constitutes four different types of glue. In a project you need to specify a given number of extensions of each types. Most of the cases are covered by action and component extensions. The Service Layer provides the definition of all these types of extensions, and the SDK provides a lot of default behaviors for the extensions.

The default behaviors are usually the one you need in 90% of the time.

For the remaining 10%, you will have to override the default behavior (in Object Oriented Programming, this will lead to redefinition of an inherited method).

These four extension typescorrespond to four well-known principles in software architecture design, and lead to the separation between, respectively:

• Processing logic
• Data logic
• Application logic
• Presentation and interaction logic

The CamiTK Community Edition includes a dedicated tutorial project that contains loads of source code examples. Please check the tutorials documentation page for examples of extensions. It will give you some idea to start developing your own extensions.

Which type should I consider (use case)?

The table below gives you a list of use cases for the four types of extensions.

Type	Description/Need	Examples	Solutions
	- View a new mesh, graph scene or image format - Connect a new device to view its data, control its parameters/actions	- Import .obj format - View 3D Ultrasound images - Connect a medical robot or sensor - Connect a motion tracker device to interact with the 3D viewer	- Create a new component extension that inherits from basic ones (MeshComponent, ImageComponent) Or Create a new generic component extension Or combine existing components in a new one
	- Transform some data - Generate new information from some data A new way of interacting with available view	- Image filter, volume reconstruction - Biomechanical simulation using a specific method - Export a data to a specific format - Mesh/image registration - Fly camera in 3D using a path of key position and timer - Take regular screenshots of one viewer to create a movie	1 - Choose which component is concerned (what is the input data of the new algorithm) 2 - Create a new action extension
	- New type of interaction with the data - A new way of visualizing the data	- Graph of values computed by an action Histogram of data from a component	- Create a new viewer extension Or inherit from an existing one and add/redefine a behavior
	- You need a specific GUI for your specific CAMI application	- An application that guides the user through a pipeline of predefined actions - No 2D/3D interaction, just data explorer and property viewer - A Specific application to test on a group of user (including specific log - or trace)	- Use the provided Action State Machine application Or choose which software component you need in the main window and create a new MainWindow extension

Table 1. CamiTK extension use cases: what type of extension should you consider, depending on your need

How can I apply an action (processing) to a component (data)?

CamiTK provides all the mechanisms to automatically present to the user the available actions considering the currently selected component.

• If you are using an interactive application (e.g., camitk-imp), first open and select some component instance, and then click on the action menu, use the right-click to popup the contextual menu, or use the action viewer to browse the list of available actions.
• If you are not using an interactive application (e.g., you are running a kind of script), then you need to do everything programmatically using the CamiTK API (there are simple method to select a component instance and trigger a given action).
• If you want to run an action pipeline (e.g., your are using the action state machine) , simply define the in/out data of the pipelined actions

Note : the actions that are only creating data (for example: open a file, generate a generic cubic mesh…) can be applied when no components are selected.

Where are all these marvelous extensions installed and how to access them?

Extension are made available (i.e. loaded at launch time) without any action required on your side as long as they are installed or located in, what we call, an extension repository.

There are three possibles extension registries, also called installation directories:

• The global repository: this is where CamiTK SDK is installed
• The local repository: it is only available for the current user, it is installed in the user configuration directory (Directory %APPLICATION\_DATA% on Windows, $HOME/.config on Unix and MacOs)
• The build repository: this is the build tree currently used by the developer to create its new extensions

The build repository is useful during the development of a project: you don’t need to install your extension at each build. They will be automatically found in the build repository.

Once you are satisfied with it you can either install it in the global or local repository.

How should I organize all my extensions?

To simplify the development and distribution of extensions, a set of CamiTK extensions can be grouped into a [CamiTK Extension Project (CEP)]/docs/getting-started/projects/). A CEP basically regroups all the extensions developed by a specific person or group for a specific field or project.

Developing CEP facilitates task oriented project and helps you to focus on the most important/valuable code. It also provides a natural way of maturing your code.

Where should I go next?

Ready to go? These are probably the next steps:

• [Understand CamiTK Extensions Projects]{({%relref “projects”%}}): What are the main important things to understand about CEP
• Examples: Check out some example code!