\item \texttt{Name}: The name of a box or an application (e.g. \texttt{Reader}, \texttt{example}).
\item \texttt{Description}: A part of the description of a box (e.g. \texttt{3D}, \texttt{image}).
\item \texttt{Category}: The categories of the box (e.g. \texttt{demo}).
-\item \texttt{Input/Output Type}: The \CPP type of an input or output (e.g. \texttt{vtkImageData*}, \texttt{std::string}).
+\item \texttt{Input/Output Type}: The \CPP type of an input/output (e.g. \texttt{vtkImageData*}, \texttt{std::string}).
\item \texttt{Input/Output Nature}: The \texttt{nature} of an input or output (e.g. \texttt{file name}, \texttt{signal}).
\end {itemize}
By : laurent.guigues@creatis.insa-lyon.fr
Categories : atomic box;math;
* Inputs :
- 'BoxExecute' <bbtk::Void> [signal] : Any signal received...
+ 'BoxExecute' <bbtk::Void> [signal] : Any signal received ...
executes the box
- 'BoxProcessMode' <String> [] : Sets the processing mode...
- (Pipeline | Always |...
+ 'BoxProcessMode' <String> [] : Sets the processing ...
+ (Pipeline | Always...
'In1' <Double> [] : First number to add
'In2' <Double> [] : Second number to add
* Outputs :
\begin{verbatim}
# bbAdd3.bbs: defines the Add3 black box which adds 3 doubles
-
-author "myself"
-description "adds 3 doubles"
-
load std
+
define Add3
+ author "myself"
+ description "adds 3 doubles"
+ category "example"
+ category "misc"
# Pipeline creation
new Add a
new Add b
\item The commands \texttt{author}, \texttt{description}, \texttt{input}
and \texttt{output} are specific to complex boxes definition:
\begin{itemize}
- \item \texttt{author} and \texttt{description} are used for the documentation
-of the new box. They have to be placed at the very beginning of the script file. You can provide multiple \texttt{author} or
-\texttt{description} commands, the arguments of the commands will
-be concatenated to produce the final author and description strings.
+ \item \texttt{author}, \texttt{description} and \texttt{category} are used for the documentation of the new box. You can provide multiple \texttt{author} or \texttt{description} commands, the arguments of the commands will be concatenated to produce the final author and description strings. As for multiple \texttt{category} commands, each of them produces a separate entry for the documentation.
\item \texttt{input} and \texttt{output} are used to define the inputs and outputs
of the new complex box. Their syntax is the same: for each new input/output you need to say
to which internal input/output it corresponds and to provide
Complex Black Box <user::Add3>
adds 3 doubles
By : myself
+ Category(s) : complex box;example;misc;
* Inputs :
'x' <double> [] : first double to add
'y' <double> [] : second double to add
\paragraph{Summary}
%\hrule
\begin{itemize}
- \item The \texttt{author} and \texttt{description} commands, placed at the very beginning of a script file, allow to document the new type of box.
\item The \texttt{define/endefine} commands allow to define complex black box types, i.e. types of black boxes made up of other black boxes.
-Inside a \texttt{define/endefine} block :
+Inside a \texttt{define/endefine} block:
\begin{itemize}
+ \item the \texttt{author}, \texttt{description} and \texttt{category} commands allow to document the new type of box,
\item the \texttt{input} and \texttt{output} commands allow to define the inputs and outputs of the new type of box, that is to which inputs and outputs
of internal boxes they correspond.
\end{itemize}
\begin{file}{bbAdd4.bbs}
\begin{verbatim}
# Defines the Add4 black box which adds 4 doubles
-author "myself"
-description "adds 4 doubles"
-
include bbAdd3
+
define Add4
+ author "myself"
+ description "adds 4 doubles"
new Add3 a
new Add b
connect a.result b.In1
'y' <double> : second number to add
\end{verbatim}
-This is particularly useful to learn about the usage of the application, namely about the inputs that are to be set at execution. To improve the help provided, use the \texttt{description}
-and \texttt{author} commands in the script file defining the application:
+This is particularly useful to learn about the usage of the application, namely about the inputs that are to be set at execution. To improve the help provided, use the \texttt{description}, \texttt{author} and \texttt{category} commands at the beginning of the script file defining the application:
\\
\\
\begin{file}{add.bbs}
\begin{verbatim}
description "Adds two numbers"
author "foo@bar.com"
+category "example;math"
load std
new Add a
input x a.In1 "first number to add"
\end{verbatim}
\end{file}
-Now if you ask for help on the \texttt{add} script, you get :
+Note that (at least for the moment and contrary to the definition of complex black boxes) you cannot use here multiple \texttt{description}, \texttt{author} and \texttt{author} commands. If the application belongs to several categories, you have to write a single string listing the categories separated by semi-colons, like in the example above. Now if you ask for help on the \texttt{add} script, you get :
\begin{verbatim}
> bbi add -h
Adds two numbers
By : foo@bar.com
+ Category(s) : example;math;
* Inputs :
'x' <double> : first number to add
'y' <double> : second number to add
There is a special kind of widget, called '\texttt{Layout}', designed to
contain other widgets in order to build larger dialog boxes.
-For example, the \texttt{LayoutSplit} widget is a container which
+For example, the \texttt{LayoutSplit} widget is a container that
``splits'' a window into two parts, either horizontally or vertically,
each part including another widget.
The initial size of the two parts can be fixed by the input 'Proportion'
Move the sliders and close the window.
Now look at the source file to see how this is done:
-\begin{file}{scripts/test/testSplit.bbs}
+\begin{file}{CreaTools/bbtk-0.9.1/bbs/wx/appli/exampleLayoutSplit.bbs}
\begin{verbatim}
load wx
First, the two sliders \texttt{s1} and \texttt{s2} are created.
A \texttt{LayoutSplit} box \texttt{s} is also created.
-The \texttt{connect} commands then ``include'' the sliders in the
+The \texttt{connect} commands then ``insert'' the sliders in the
split widget.
-The input \texttt{Widget} is common to all widget boxes:
-every widget can be inserted into another widget.
-The outputs \texttt{Widget1}, \texttt{Widget2} are specific of \emph{layout}
-widgets
-(in \bbStudio type \texttt{help Slider}:
+The output \texttt{Widget} is common to all widget boxes: in this way
+every widget can be inserted into another widget, provided that the latter has an appropriate input permitting this insertion.
+The inputs \texttt{Widget1}, \texttt{Widget2} of \emph{layout}
+widgets are precisely such special inputs used to ``host'' other widgets.
+In \bbStudio type \texttt{help Slider}:
you will see the output \texttt{Widget};
type \texttt{help LayoutSplit}:
you will see the inputs \texttt{Widget1} and \texttt{Widget2}
-and the output \texttt{Widget}).
+and the output \texttt{Widget}. \\
+\emph{Note that the information about the inputs/outputs of widget boxes in html help is displayed in tables having 3 different color cells. From top to bottom you first find the inputs/outputs specific for the given box, then those that are common for all widget boxes, finally those that are common for all black boxes.}\\
When you connect the \texttt{Widget} output of a box
-to the \texttt{Widget}i input of a layout widget,
-you order to include the widget in the layout.
+to the \texttt{Widget}\textit{i} input of a layout widget,
+you order to insert the widget in the layout via its \textit{i}-th special input.
Of course, the order of connection is important.
-In our case, the slider \texttt{s1} is included first,
-then the slider \texttt{s2}: \texttt{s1} will be placed
+In our case, the slider \texttt{s1} is inserted first,
+then the slider \texttt{s2}. So, \texttt{s1} will be placed
on top of \texttt{s2} (the \texttt{LayoutSplit} box is
-implemented that way, but this is arbitrary choice).
+implemented that way, but this is an arbitrary choice).
Right now, there are only \emph{three} layout widgets in the \texttt{wx} package :
\begin{itemize}
\item {the \texttt{LayoutSplit} widget} we just described
\item {the \texttt{LayoutLine} widget} can have multiple children
-(\texttt{Widget1}, \texttt{Widget2},\dots \texttt{Widget9} inputs) and
+(\texttt{Widget1}, \texttt{Widget2},{\dots} \texttt{Widget9} inputs) and
divides its window into as much parts as children,
each part of equal size.
-The orientation of the \texttt{LayoutSplit} or of the \texttt{LayoutLine} can be changed by the input \texttt{Orientation}.
+The orientation of the \texttt{LayoutSplit} or of the \texttt{LayoutLine} can be changed by the input \texttt{Orientation}.
With only those two layout widgets you can already create
complex dialog boxes
(of course layouts can be nested, which leads to tree-like
See the script \texttt{exampleComplexLayoutSplit\_In\_LayoutSplit} for an example.
\item {The \texttt{LayoutTab} widget} arranges its children
-in different pages or 'tabs' (\texttt{wxNotebook}-based).
+in different pages or 'tabs' (based on \texttt{wxNotebook}).
The label of each page is the name of the widget it contains.
\end{itemize}
%the \texttt{Button}... to be continued.
% ==========================================
-\subsection{Deeper in the boxes}
+%\subsection{Deeper into the boxes}
+%\label{bbi-deep-box}
+% ==========================================
+% ==========================================
+\subsection{Default and mandatory inputs and outputs}
\label{bbi-deep-box}
% ==========================================
-\subsubsection{Default and mandatory inputs and outputs}
-\begin{itemize}
-\item Any \texttt{atomic} black box has two default Inputs, which are created by the system :
+%\subsubsection{Default and mandatory inputs and outputs}
+Any {\bf\emph{atomic}} black box has two default inputs and one default output (listed below) that are created by the system. If you create a complex boxes, it is a good idea to also define these two inputs and one output for this new box, in order to be able to use your complex box in the same way as the atomic boxes.
\begin{itemize}
- \item {\bf\emph{BoxExecute}} : Any signal received by this input executes the box
- \item {\bf\emph{BoxProcessMode}}: Sets the processing mode of the box :
- \begin{itemize}
- \item {\bf\emph{Pipeline}}:% bbBackwardUpdate() calls Process() only if Status == MODIFIED \\
- The box executes itself only when an input was changed (normal pipeline processing).
- \item {\bf\emph{Reactive}}: %bbSetModifiedStatus() calls bbUpdate() \\
- Re-processes immediately when \emph{any input} changes.\\
- To be more selective, better use
- '\texttt{connect A.BoxChange B.BoxExecute}'.
- \item {\bf\emph{Always}} :% bbUpdate() always calls Process. \\
- Usefull for 'sources', that must be processed, even when no input changed (e.g.: FileSelector, ColorSelector)\\
- This one is not end user intended (for Package developer only)
- \end{itemize}
-\end{itemize}
-\item And one default output :
-\begin{itemize}
- \item {\bf\emph{BoxChange}} : Signals any modification of the box. This output may be connected if necessary to the \emph{BoxExecute}
- input of an other box : each time the boxes changes (e.g. a Slider is moved) the box it is connected to will be forced to update.
+ \item Inputs:
+ \begin{itemize}
+ \item {\bf\emph{BoxExecute}}: any signal received by this input executes the box.
+ \item {\bf\emph{BoxProcessMode}}: sets the processing mode of the box:
+ \begin{itemize}
+ \item {\bf\emph{Pipeline}}: % bbBackwardUpdate() calls Process() only if Status == MODIFIED \\
+ This is the normal pipeline processing mode, i.e. when an execution of \emph{my\_box} is requested (either by the command '\texttt{exec my\_box}' or because another box dependent on \emph{my\_box}'es output is to be executed), \emph{my\_box} actually executes itself only if at least one of its inputs was changed.
+ \item {\bf\emph{Reactive}}: %bbSetModifiedStatus() calls bbUpdate() \\
+ \emph{my\_box} re-executes itself immediately when \emph{any input} changes.
+ To be more selective, i.e. if you want to re-execute immediately only when one specific input changes, dependent on the change of a particular \emph{other\_box}, better use
+ '\texttt{connect other\_box.BoxChange my\_box.BoxExecute}'.
+ \item {\bf\emph{Always}}: % bbUpdate() always calls Process. \\
+ Useful for 'sources', that must be processed in the pipeline mode despite no input change (e.g.: FileSelector, ColorSelector).
+ This one is not end user intended (for Package developers only).
+ \end{itemize}
+ \end{itemize}
+ \item Output:
+ \begin{itemize}
+ \item {\bf\emph{BoxChange}}: signals any modification of the box. This output may be connected if necessary to the \texttt{BoxExecute}
+ input of another box: each time the box changes (e.g. a Slider is moved) the box it is connected to will be forced to update.
+ \end{itemize}
\end{itemize}
-If you create complex boxes, it is a good idea to define those inputs and outputs to be able
-to force the execution of your complex box or be aware of its changes...
-
-\item Any {\bf widget} box has five Inputs, that will be dealt with only if the box is not connected to the \emph{Widget}i of any \emph{Layout} box :
+Any {\bf\emph{widget}} box has five \emph{inputs}, that will be dealt with only if the box is not connected to the \texttt{Widget} input of any {\bf\emph{layout}} box. If you define a complex widget box, it is a good idea to define these inputs to be able to customize your window settings. It has also one mandatory \emph{output}. If you define a complex widget box, it is a good idea to use the same standard name for your window output.
\begin{itemize}
- \item {\bf\emph{WinHeight}}: Height of the window
- \item {\bf\emph{WinWidth}} : Width of the window
- \item {\bf\emph{WinTitle}} : Title of the window
- \item {\bf\emph{WinClose}} : Any received signal closes the window
- \item {\bf\emph{WinHide}} : Any received signal hides the window
- \item {\bf\emph{WinDialog}}: When set to 'true', creates a \emph{dialog window}, that blocks the pipeline until it is closed (\emph{modal})
+ \item Inputs:
+ \begin{itemize}
+ \item {\bf\emph{WinHeight}}: Height of the window.
+ \item {\bf\emph{WinWidth}}: Width of the window.
+ \item {\bf\emph{WinTitle}}: Title of the window.
+ \item {\bf\emph{WinClose}}: Any signal received by this input closes the window.
+ \item {\bf\emph{WinHide}}: Any signal received by this input hides the window.
+ \item {\bf\emph{WinDialog}}: When set to \texttt{true} or $1$, the widget behaves as a \emph{dialog window} that blocks the pipeline until it is closed (\emph{modal}).
+ \end{itemize}
+ \item Output:
+ \begin{itemize}
+ \item {\bf\emph{Widget}}: Represents the \texttt{wxWindow} itself. If it is not connected to the \texttt{Widget}\emph{i} of any {\bf\emph{layout}} box, then the box will create its own window (frame or dialog) on execution. If it is connected to the \texttt{Widget}\emph{i} of a {\bf\emph{layout}} box, it will be embedded in its parent window.
+ \end{itemize}
\end{itemize}
-If you define a complex widget box, it is a good idea to define these inputs to be able
-to customize your window settings.
-
-\item Any {\bf widget} box has one mandatory Output :
-
-\begin{itemize}
- \item {\bf\emph{Widget}}: that is the \texttt{wxWindow} itself. If it's not connected to the \texttt{Widget}\emph{i} of any \emph{Layout box}, then the box will create its own window (frame or dialog) on execution. If it's connected to the \texttt{Widget}\texttt{\emph{i}} of a \texttt{Layout box},
- it will be embedded in its parent window.
-\end{itemize}
-
-If you define a complex widget box, it is a good idea to use this standard name for your window output
+Any {\bf\emph{layout}} box (i.e. \texttt{LayoutLine}, \texttt{LayoutSplit} or \texttt{LayoutTab}) has one or more mandatory inputs {\bf\emph{Widget}}\texttt{i} indexed by their number \emph{i}, e.g.: a \texttt{LayoutSplit} box (widget that splits a window in two resizable parts) has two inputs \texttt{Widget1} and \texttt{Widget2}, used to embed the child windows. If you define a complex layout box, it is a good idea to use these standard names for your
+sub-windows inputs.
-\item Any {\bf Layout} box (i.e. \emph{LayoutLine}, \emph{LayoutSplit} or \emph{LayoutTab}) has one or more mandatory Inputs :
-\begin{itemize}
- \item {\bf\emph{Widget}}\texttt{i}: e.g. a \emph{LayoutSplit} box (Widget which splits a window in two resizeable parts)
- has two Input parameters \emph{Widget1} and \emph{Widget2}, used to embed the child windows.\\
- e.g. a \emph{LayoutLine} divides the window in up to 9 (depending on the number of inputs \emph{Widget}i) fixed size parts.
-\end{itemize}
-If you define a complex layout box, it is a good idea to use these standard names for your
-sub-windows inputs.
-
-\end{itemize}
% ==========================================
% ==========================================
-%\vspace{0.5cm}
+\vspace{0.5cm}
\hrule
\newpage
-\section{Using third party Package}
+\section{Using third party Packages}
\label{Third_Party_Package}
% ==========================================
% ==========================================
\subsubsection{Linux users}
\label{Installing_a_Package_for_Linux_users}
-After compiling a Package, at install time, think of using :
+After compiling a Package, at install time, use:
\begin {verbatim}
su -
make install
\end{verbatim}
-and neither :
+and neither:
\begin {verbatim}
su
make install
\end{verbatim}
-nor :
+nor:
\begin {verbatim}
sudo make install
\end{verbatim}
otherwise package documentation will not be generated. \\
-Think of updating your environment variable LD\_LIBRARY\_PATH (in .bashrc in
-you're using bash), to add the path to the shared library
-libbb\emph{YourNewPackageName}.so
+Then update your environment variable LD\_LIBRARY\_PATH (in .bashrc if
+you are using bash), to add the path to the shared library
+\texttt{libbb\emph{YourNewPackageName}.so}
% ==========================================
\label{Installing_a_Package_for_Windows_users}
% ==========================================
Think of updating your environment variable LD\_LIBRARY\_PATH to add the path to the dynamic library
-bb\emph{YourNewPackageName}.dll
+\texttt{bb\emph{YourNewPackageName}.dll}
% ==========================================
\subsection{Plugging in a Package}
\label{Plugging_in_a_Package}
% ==========================================
-\bbStudio makes it easy for you : in the menu \texttt{Tools} just click on the
+\bbStudio makes it easy for you: in the menu \texttt{Tools} just click on the
option \texttt{Plug Package}. You will be asked to '\texttt{Select
-package directory}'. Browse untill you find the install or the build directory,
-depending whether you installed the package or not.
+package directory}'. Browse until you find the install or the build directory,
+depending on whether you installed the package or not.
\bbStudio will update the configuration file, generate the 'Package
documentation', and update the 'Boxes Lists'.
\subsection{Updating the documentation}
\label{Updating_the_documentation}
% ==========================================
-You may add your own boxes (simple boxes, if you are aware enough in \CPP
-language, or complex boxes if you are aware enough in bbtk scripting).
+You may add your own boxes (simple boxes, if you are aware enough of \CPP
+language, or complex boxes if you are aware enough in \bbtk scripting).
To update the html help of this package,
use the option \texttt{Regenerate package doc}
in the menu \texttt{Tools} of \texttt{bbStudio}.
You'll be prompted for the Package name.
-Avoid using the \texttt{-a} option (Regenerate all), since it's time consumming.
+Avoid using the \texttt{-a} option (Regenerate all), since it's time consuming.
To update html boxes lists with the new boxes,
use the option \texttt{Regenerate Boxes Lists}
%\newpage
% ==========================================
-%\vspace{0.5cm}
+\vspace{0.5cm}
\hrule
\newpage
\section{Using black boxes in \CPP programs}
black box within a \CPP program
without worrying about writing a \wx main application.\\
-Let's look a the following bbs script :
+Let us have a look at the following \bbs script:
\begin{verbatim}
# Load the packages
and display the slider value in the output text.
Think about the (little!) nightmare to code the same, in 'raw C++', using wxWidgets.
-The following \CPP code does the same :
+The following \CPP code does the same:
\begin{verbatim}
#include <bbtkFactory.h>
{
try
{
- // we need to intanciate a bbtk::Factory to be aware of the adaptors
+ /* we need to instanciate a bbtk::Factory
+ to be aware of the adaptors*/
+
bbtk::Factory::Pointer factory = bbtk::Factory::New();
// Load the packages
// Create the Objects
// ------------------
- bbwx::Slider::Pointer slider = bbwx::Slider::New("slider");
- bbwx::OutputText::Pointer text = bbwx::OutputText::New("text");
- bbwx::LayoutLine::Pointer layout = bbwx::LayoutLine::New("layout");
+ bbwx::Slider::Pointer slider = bbwx::Slider::New("slider");
+ bbwx::OutputText::Pointer text = bbwx::OutputText::New("text");
+ bbwx::LayoutLine::Pointer layout =
+ bbwx::LayoutLine::New("layout");
// Graphical pipeline
- bbtk::Connection::Pointer c1 = bbtk::Connection::New(slider,"Widget",
- layout,"Widget1");
+ bbtk::Connection::Pointer c1 =
+ bbtk::Connection::New(slider,"Widget",layout,"Widget1");
- bbtk::Connection::Pointer c2 = bbtk::Connection::New(text,"Widget",
- layout,"Widget2");
+ bbtk::Connection::Pointer c2 =
+ bbtk::Connection::New(text,"Widget",layout,"Widget2");
// Execution pipeline
// ------------------
- // We have to pass the 'factory', in order to call automatically an adaptor,
- // if necessary.
- bbtk::Connection::Pointer s2t = bbtk::Connection::New(slider,"Out",
- text,"In",
- factory);
- bbtk::Connection::Pointer c3 = bbtk::Connection::New(slider,"BoxChange",
- text,"BoxExecute");
+ // We have to pass the 'factory', in order to call
+ // automatically an adaptor, if necessary.
+ bbtk::Connection::Pointer s2t =
+ bbtk::Connection::New(slider,"Out",text,"In",factory);
+ bbtk::Connection::Pointer c3 =
+ bbtk::Connection::New(slider,"BoxChange",text,"BoxExecute");
layout->bbSetInputWinDialog(true);
// Go!
e.Print();
}
}
+\end{verbatim}
In this code, we use the headers of the \texttt{bbwx} \CPP library,
which define the black boxes of the \texttt{wx} package.
+\vspace{0.5cm}
to be continued ...
-\end{verbatim}
% ==========================================
+\vspace{0.5cm}
\hrule
\newpage
\section{\bbs language reference}
Sets the input \texttt{input} of
the box named \texttt{box} to the value \texttt{value}.
An \texttt{adaptor} must exist
-in the packages loaded which converts a \texttt{std::string}
+in the packages loaded, which converts a \texttt{std::string}
to the type of the input \texttt{input}. \\ \hline
\texttt{exec} & \texttt{<box-name>} &
\label{bbi-reference-package}
\begin{table}[!ht]
-\caption{\label{tabbbi-reference-interpreter_1}\bbs package related commands. }% (part 1).}
+\caption{\label{tabbbi-reference-package_1}\bbs package related commands. }% (part 1).}
\small
\begin{tabular}{|lcm{6cm}|}
\hline
%See table \ref{tabbbi-reference-interpreter_1} and \ref{tabbbi-reference-interpreter_2}
% ==========================================
\begin{table}[!ht]
-\caption{\label{tabbbi-reference-interpreter_1}\bbs intepreter related commands. }% (part 1).}
+\caption{\label{tabbbi-reference-interpreter_1}\bbs interpreter related commands. }% (part 1).}
\small
-\begin{tabular}{|lcm{6cm}|}
+\begin{tabular}{|lcm{7cm}|}
\hline
Command & Parameters & Effect \\ \hline
\texttt{box-type}.
The box type must belong to a package which has been previously loaded \\ \hline
+& \texttt{<box-name>} &
+Prints help on the existing box instance named
+\texttt{box-name} (i.e. created by \texttt{new} command), including the state of its inputs/outputs \\ \hline
+
\texttt{message}
& - &
Prints information on available kinds of messages and their current level\\ \hline
Prints the string after substituting each token of the form \texttt{\$box.output\$} by the adaptation to string of the value of the
output \texttt{output} of the box named \texttt{box}.
An \texttt{adaptor} must exist
-in the packages loaded which converts
+in the packages loaded, which converts
the type of the output \texttt{output}
to a \texttt{std::string}.
\\ \hline
\texttt{define} & \texttt{<box-type>} [\texttt{<package-name>}] &
Starts the definition of a complex black box of type
-\texttt{box-type}. If \texttt{<package-name>} is provided then includes the
-box in the given package (otherwise it is defined in the current package,
-i.e. \texttt{user} if outside a \texttt{package/endpackage} block). \\ \hline
+\texttt{box-type}, and includes it either in the given package (if \texttt{<package-name>} is provided) or in the current package,
+i.e. \texttt{user} if outside a \texttt{package/endpackage} block. \\ \hline
\texttt{endefine} & - &
Ends the definition of a complex black box type\\ \hline
\texttt{author} & \texttt{<string>} &
-Concatenate the string to the author string
+Concatenates the string to the author string
of the current complex black box.\\ \hline
\texttt{description} & \texttt{<string>} &
-Concatenate the string to the description of the current complex black box.
+Concatenates the string to the description of the current complex black box.
\\ \hline
\texttt{category} & \texttt{<string>} &
The categories must be separated by semicolons, e.g. "\texttt{widget;image}"\\ \hline
\texttt{kind} & \texttt{<box kind>} &
-Specifies the \texttt{kind} of the current complex black box
-( ADAPTOR, DEFAULT\_ADAPTOR, WIDGET\_ADAPTOR, DEFAULT\_WIDGET\_ADAPTOR )\\ \hline
+The following \texttt{kind}s are defined:
+
+DEFAULT\_ADAPTOR,
+ADAPTOR, DEFAULT\_WIDGET\_ADAPTOR, WIDGET\_ADAPTOR\\ \hline
\texttt{input} & \texttt{<name>} \texttt{<box.input>} \texttt{<help>} &
Defines a new input for the current complex black box,
obtained in \bbStudio by clicking on the
\texttt{Config} button of the \texttt{Command} part toolbar.
-If you did not installed other packages than the ones
+If you did not install other packages than the ones
provided by \bbtk, you get something like :
\begin{verbatim}
git://git.creatis.insa-lyon.fr / bbtk.git / commitdiff