camitk.Action

class camitk.Action

Action class is an abstract class that enables you to build a action (generally an algorithm that works on specific data, i.e. a specific component).

To write an new action extension, at least two classes have to be reimplemented to enable the action: ActionExtension + Action. All the plugin mechanism is simplified thanks to CamiTK extension files (a JSON file containing all the information to generate the glue between your code and CamiTK).

Overview

This is the list of attributes you need to consider when creating a new action - name: name of the action; - description: tag used to describe the action (also used for tooltip and whatsThis of the corresponding QAction); - componentClassName: the name of the component class on which this action can be applied or “” (default) for generic actions. It determines on which type of component your action can be applied. Generic actions are action that have an empty component class name. Therefore generic actions can be called to generate/synthetize data or initialize resources. - family: families of actions allows one to group different actions of the same kind under one name; - tags: tags is a list of words used to define an action. These words can be used to find an action. - gui: either “Default Action GUI” (the action uses a default widget, instance of ActionWidget), “No GUI” or “Custom GUI” (you need to create the action’s gui widget) - notEmbedded: this boolean defines if the gui widget is embedded in a given parent widget / action widget container (true by default) or not - icon: the icon used for the visually distinguish the action (used by the corresponding QAction)

An Action has a corresponding QAction, see getQAction(), that makes it easy to trigger an action from any Qt GUI (menus, toolbar, push buttons…). You can also call your action programmatically from any other code.

If the component class name is not empty, the action is using the currently selected components of the given type (class name). If the component class name is empty, the action does not need any input.

Using CamiTK extension file

Using CamiTK extension file simplifies the creation and modification of actions. When using a CamiTK extension file, the extension generator will generate a initial .cpp file that you just have to fill in with your source code.

These are the five methods you need to consider for customization: - init() is called when the action is loaded by the extension manager (i.e., when the action is instantiated). This is where all instance wide initialization should be done - process() is called when the user presses the “Apply” button. This is the main code for the action, where things are done - targetDefined() is called when the target of the action are defined (i.e., when the action is triggered). It is generally used to update the action GUI - parameterChanged() is called when a parameter value has changed. Similarly to targetDefined() it can be used to update the action GUI - (optional) getUI() if the developer wants to have a custom GUI, this is where she/he should instantiate the corresponding widget(s)

You can call refreshApplication() in order to force the viewers to refresh.

Action Parameters

Action parameters are automatically created from the CamiTK extension files. Each parameter is defined as a Qt dynamic property. In your C++ code it is strongly recommended to use: - getParameterValue(“My Parameter”) to get the value as a QVariant (you can they use toString(), toBool(), toDouble()… depending on the type of “My Parameter”) - setParameterValue(“My Parameter”, newValue) to set the value of a parameter programmatically (newValue must be a QVariant or of type that can be converted to a QVariant) - getParameterValueAsString(“My Parameter”) to get a string representation of the value of “My Parameter”

Default GUI, Custom GUI or no GUI?

An Action generally is used to wrap an algorithm in CamiTK. If this algorithm has parameters, it is very easy to get these parameters accessible to the user through the ActionWidget. These parameters are in fact defined as Qt dynamic properties.

The default widget is an instance of ActionWidget. If ActionWidget does not correspond to what you need, just declare your action as having a Custom Widget You will then need to create a new class inheriting from QWidget, or directly from ActionWidget.

These are the use cases for using the default behaviour (i.e. an instance of ActionWidget): - your action has some parameters and you need the user to review the default or modify their values before the action is applied, - or your action has no parameters but you still want the user to be applied only if/when the user click on an apply button.

ActionWidget should be good enough in most of the cases. The default widget contains a description, a reminder of the current target component names, and an ObjectController with an Apply/Revert buttons that allows you to edit/modify properties. Use setDefaultWidgetButtonVisibility() to change the visibility of the Apply/Revert buttons and setDefaultWidgetApplyButtonText() to change the apply button text.

When an action has no GUI triggering the action will directly call process()

The recommended architecture is for the action widget to call the action’s apply method. The widget should only manage user interaction.

Underlying triggering and applying an action mechanism

Two steps have to be considered when using an action: - Step 1, trigger(): the action is either directly applied (if it does not have any GUI) or it’s GUI is shown (using getWidget()) - Step 2, apply(): only the action algorithm is applied, i.e., the data are processed

The targets can have changed between the time the action is first triggered and the time the action is applied. getWidget() is always called when the targets are updated. Therefore whenever getWidget() is called, you should make sure to update the the action GUI consequently. getTargets() is always updated in trigger() and available.

trigger() and apply() are public slots. They can be called either directly (classic C++ method invocation) or by connecting them to a QWidget signal.

When an action is triggered (e.g., by right clicking in the context menu), the following algorithm applies, see trigger(): - 1. Prepare targetComponents (available with getTargets()): only select the compatible components from the selected components - 2. If the action is embedded, get the widget and show it in a parent/container (if parent is not specified, show it in the action viewer) - 3. If the action in not embedded, show it as a dialog - 4. If the action does not have any widget, directly call apply()

This means that, if there is a widget, the action algorithm is controlled by the action widget, i.e. apply() is not called by trigger() but should be called by one of the action widget’s button.

If ActionWidget is not what your need, a typical getUI() method should use the lazy instantiation pattern to instantiate MyVerySpecialActionWidget the first time it is called, and call the MyVerySpecialActionWidget instance’s updateTargets() method for any subsequent calls. Something like:

QWidget *MyAction::getUI() {
    // build or update the widget
    if (!myWidget)
        myWidget = new MyVerySpecialActionWidget(this);
    else
        // MyVerySpecialActionWidget should have an update() method
        myWidget->update();

    return myWidget;
 }

But of course you can also use any kind of widget you like. ActionWidget is just defining a default widget for an action. If your action does not have any GUI/parameters, add a getWidget() and return nullptr.

By default the properties/parameters are automatically updated when the user change the default widget, they are updated only when the user click on the apply button of the default widget. The setAutoUpdateProperties(true) to automatically called. Use parameterChanged() to perform some action when a parameter was changed byt the user.

By default the action’s widget is embedded. If you do not want to embed your action’s widget, modify the “notEmbedded” parameter. When embedded, the parent widget has to be given at triggered time (i.e. getUI() is called during trigger). If there is no parent given for an embedded action, then the action is embedded in the ActionViewer by default.

The method apply() must be implemented in your Action.

at any moment, the selected components on which the action needs to be applied are available by getTargets(). targetComponents is filtered so that it only contains compatible components (i.e., instances of getComponent()).

About registering your action in the history of the application. Consider registering your action within the application’s history once applied. The history of action features a stack of processed action. The application’s history of actions allows one to export the saved actions as an XML file for scripting or replaying it. To do so, implement the apply() method in your code, then launch the method applyAndRegister(), which simply wraps the apply() method with the preProcess() and postProcess() methods. You may also connect a SIGNAL to it, as the applyAndRegister() method is a Qt SLOT.

Creating a pipeline of actions

A pipeline of actions is a state machine where each state stands for an action with inputs and output components. The transitions between the states are done by processing the state’s action (i.e. by calling the corresponding action’s apply() method). Interpreting an pipeline of action is simpler than simply executing the action since the user doesn’t need to manually set the inputs and outputs of each action (it is done automatically). If you are willing to write such a pipeline, simply implements the apply() method of each of your action and called the applyInPipeline() (instead of simply apply()). The method applyInPipeline() performs some pre- and post-processing around the method apply(). It has to be used within a pipeline (a chain of actions) where setInputComponents() and getOutputComponents() are needed. preProcessInPipeline() only selects the right components, and postProcess() sets output components and record history.

See also

RenderingOption For a simple example of an embedded action

See also

RigidTransform For a simple example of a non-embedded action

ChangeColor For a simple example of an action with no widget (but with a GUI)

__init__(*args, **kwargs)

Methods

__init__(*args, **kwargs)
addParameter(self, arg0)	Add a new parameter to the action, using the CamiTK property class.
getName(self)	get the name of the action
getOutputComponent(self)	Returns the top-level output Component of this Action, or None if there is no output.
getParameterValue(self, arg0)	get the parameter QVariant (same as property(const char*)) but check if it exists first.
getProperty(self, arg0)	Get a Property given its name
getTargets(self)	the currently selected and valid (regarding the component property) components, for which this action is called
refreshApplication(self)	convenient method to call from the user code to refresh all the application This is equivalent to call Application::refresh()
saveState(self)	Saves the current state of this Action, including its parameters.
setApplyButtonText(self, arg0)	modify the "Apply" button text
setInputComponent(self, arg0)	Assigns the given Component as input to this Action.
setParameterValue(self, arg0, arg1)	set the parameter QVariant value (same as setProperty(const char*, newValue)) but check if it exists first.
updateWidget(self)	Updates the Action's default widget, if any.

Attributes

ABORTED
ERROR
SUCCESS
TRIGGERED
WARNING