The component package is a zip file with a known directory structure.
Each component in the package is described by a
The Builder provides a user interface for creating a component package
out of the current app directly. If you want to create other types of
components, you need to create the directory structure manually and then
use the Builder or a command-line tool to
compile the package file.
We’ll use the edge detector app as an example. The target is to create an app can be triggered to process a file on the local hard drive through an HTTP request. The app will send the processing results as signals.
Click File, Open… and choose the directory you saved the project into. The Builder will show you the platform’s file dialog, the picture below shows a Qt dialog in Linux.
As a first step, we’ll give our app a component ID. The component ID will uniquely identify the app and its API. Select File, App properties… and change the auto-generated component ID to “com.example.edgedetector”. If your intent is to sell or otherwise distribute the app through the Store, you need to register the component ID using your seller account.
The virtual camera the app was set up with reads images from your hard
drive, which will not be accessible by the users of the app. The next
step is to change this so that the name of the image file will come
through an API call. Change the
Camera Id parameter to “File name
Note that this will cause the processing graph to stop because there is no longer a camera from which images could be read. You can dismiss the error message by clicking “Restart now”.
In the context menu of the
Trigger input, select “Publish app API
function” to add the input to the API object as a function.
Open the API editor to see the app’s API. You’ll see three entries: one function and two signals. Since we dragged two output parameters to an image display, the Builder has automatically created two signals for us. The trigger input will show up as a function.
The default names of the API entries are composed of the parameter name and an optional postfix number to make the name unique in the application scope. Since the API is intended to be used as the public interface of your app, try to find descriptive names. Click the name of the API entry (the rightmost column) to rename it.
We’ll change the default names to
edges as shown in the next picture. By convention, the names should
be in camelCase, i.e. start with a lowercase letter and capitalize the
first letter of subsequent words.
Close the API editor by clicking the API icon again and save it with Ctrl + s. Select File, Package this app… You’ll be shown a component editor dialog. Open the “Local” section and pick a target folder. Then click “Create”.
If you used the default target folder, opening the web-based management interface in a browser (http://localhost:2020/ by default) will show your component package in uploaded packages. Alternatively, you can upload the package to a running remote engine instance directly on the “Remote” section of the dialog.
Packaging tool plugins🔗
The Builder provides no GUI for creating the file system structure for components other than apps. But fear not, creating other types of components is still simple.
The VisionAppster SDK comes with a ready-to-build tool plugin that wraps some OpenCV functions. As a prerequisite, you should build that plugin as instructed here.
The build process will create
sdk/examles/opencv/build. To make the plugin library a component,
you need to create a specially named directory and put the file there.
md myopencv-1\windows-x86_64 copy sdk\examples\opencv\build\myopencv.toolplugin myopencv-1\windows-x86_64
mkdir -p myopencv-1/linux-x86_64 cp sdk/examples/opencv/build/myopencv.toolplugin myopencv-1/linux-x86_64
Tool plugins must have file extension
.toolplugin. When a component
package is created, files with that extension are marked as
toolplugin in the package manifest file and thus installed in the
tool plugin directory.
The examples are configured to build the plugin libraries with that extension, so there is no need to manually change it prior to the package creation.
When building component packages, directory names mostly don’t matter. Binary plugins must however be compiled for each supported target architecture separately and put under paths that include one of the known architecture identifiers. This lets the package builder automatically detect the target architecture. For more details, see the cross-compilation instructions.
Here is an example of the source folder contents for a package with a plugin binary for two different architectures:
When a package like this is installed, the installer will only copy the files matching the architecture of the running machine.
The final step is to create a component package in the builder. Click
File, Package a folder… Select the
Make sure to enter the correct component ID (
version number (
1.0.0). Then pick a target directory in the “Local”
section and click “Create”. Done.