Plugin Types

Uranium has a number of different plugin types. This page tries to give a short summary what these mean and how they need to be used.

Translation

Plugin translation can be done by using:

from UM.i18n import i18nCatalog
i18n_catalog = i18nCatalog("uranium") #can also be "cura" or any other type.
i18n_catalog.i18nc(translation_hint, text_to_be_translated)

Meta data

All plugins must have meta data, which is read from the init.py file of the plugin. Uranium assumes that there is a getMetaData() function for each plugin which returns a JSON dict. A number of objects can be inside this JSON which provides certain meta data. 'plugin' -> General meta data of the plugin. Can contain name, author, version and description.

Plugin Types

Output devices

Output devices are ways to get data out of the application. Examples of these are LocalOutputDevice, which saves data to (local) files.

Important to know is that output devices need to be registered with the OutputDeviceManager and are required to implement a requestWrite function (that accepts a node as parameter). If the user decides that a certain file needs to be saved / writen somewhere, the requestWrite of the active output device is called.

Views

Views are responsible for displaying Scene information to the user. An example of this type is the MeshView, which displays all mesh data in the scene as polygon objects. It is also capable of highlighting overhang (based on preferences).

It must be noted that certain SceneNodes can have their own renderer. In this case calling their render function will return True. Views can decide to ignore these and still interpret the data as they see fit, although this is not recommended (as nodes with their own Renderer will probably have a very good reason for doing so).

Tools

Tools are plugins that enable the user to modify data in the scene. Good examples of these are the Mirror tool, Rotate tool, Scale tool and Translate tool. Tools tend to also have ToolHandles, which usually contain meshes that can be drawn on a certain location. In the case of the translate tool, the tool handle is responsible for drawing the coloured arrows by which the user can move the (selected) object.

Tools can be active as three different kinds; Camera tools, Selection tool and Active tool. Events are passed to the different tools in order (Camera tool will receive any event first. If it does not handle it or there is no Camera tool it will be passed to the selection tool and so forth).

The following meta data options are available for tools:

"tool": {
        "name": "tool name",
        "description":"Description of tool",
        "icon": "icon for tool",
        "tool_panel": "QML file with extra options (optional)"
}

Extentions

Extentions are plugins that enable certain operations that are not quite tools but do require some form of user action to be activated. A good example of this is the UpdateChecker plugin. Although it does automatically check for a new version, it requires user action before a new version is downloaded. Extensions are able to add menu items to the extensions dropdown menu in the top bar. Note that a single extension can add multiple items, which are grouped by the name of the extension that added them. You can add a new option to the menu by using:

self.addMenuItem(text_of_menu_item, function_that_is_activated)

Backend

Only a single backend plugin should be active at any given time. The backend plugin is responsible for all communication of uranium with a stand alone service that does "the heavy lifting". In the case of Cura, this is the CuraEngine, which is responsible for the slicing of objects. The backend uses sockets to communicate with the executable and is assumed to use libArcus, which in turn depends on ProtoBuff.

Loggers

Loggers are plugin types that handle the logging events of the GUI. Uranium has two logging plugins; ConsoleLogging and FileLogging. The logging has 4 types of verbosity; "e" (error) , "i"(info), "d"(debug) and "w"(warning). The reason why this is done with plugins is to enable easy dis/enabling of logging and the potential to add remote logging if this is required in a later stage.

Mesh Handlers

In most cases if you want to support a new file type, you will need to use 2 plugins; one for writing, the other for reading.

Mesh writer

Writes a single extension type to file. Must implement:

def write(self, file_name, storage_device, mesh_data)

As mentioned in the storage device section, this is hardcoded to be local for the moment.

Mesh reader

Loads a single extension type from file. Must implement:

read(self, file_name, storage_device):

As mentioned in the storage device section, this is hardcoded to be local for the moment.