|
Ipelib
|
As in Ipe 6, it is possible to write ipelets entirely in C++. Different from Ipe 6, however, the labels of the ipelet and its functions must now be specified in a short Lua wrapper with some boilerplate code. This Lua code will invoke your C++ methods.
The C++ code is in a dynamically loaded library (DLL), that you place on Ipe's C++ ipelet path. The DLL has to be written in C++, and must export a function newIpelet that creates an object derived from the class Ipelet (defined in ipelet.h). Here is a minimal ipelet implementation:
#include "ipelet.h"
class MyIpelet : public ipe::Ipelet {
public:
virtual int ipelibVersion() const { return IPELIB_VERSION; }
virtual bool run(int function, ipe::IpeletData *data, ipe::IpeletHelper *helper);
};
bool MyIpelet::run(int function, ipe::IpeletData *data, ipe::IpeletHelper *helper)
{
// this is where you do all the work
}
IPELET_DECLARE ipe::Ipelet *newIpelet()
{
return new MyIpelet;
}
When the ipelet is executed, Ipe hands it a structure with some information about the document, in particular a pointer to the current page. The ipelet can examine the selected objects, and modify the page in any way it wishes. (It is not possible to modify the document outside the current page, as this would interfere with the undo stack). It can also request services from the Ipe application through the IpeletHelper object, for instance to display a message in the status bar, to pop up message boxes and to obtain input from the user.
The run method must return true if it modified the document page. This is used to create an item on the undo stack so that this change can be undone. If the run method returns false, then no undo stack item is created. In this case, the ipelet must not modify the page.
You need to provide a small Lua wrapper that declares the names of the ipelet and its methods, and that calls your C++ code when an ipelet method is invoked. This wrapper will look as follows:
-- Lua wrapper for C++ ipelet "myipelet"
label = "My Ipelet"
about = "This ipelet is for explanation only"
-- this variable will store the C++ ipelet when it has been loaded
ipelet = false
function run(ui, num)
if not ipelet then ipelet = assert(loadIpelet("myipelet"))
model:runIpelet(ipelet, num)
end
methods = { { label = "First function of my ipelet" },
{ label = "Second function of my ipelet" }
}
If the ipelet contains only a single method, then the methods table is omitted.
The Lua wrapper needs to be placed in Ipe's ipelet directory. When Ipe starts up, it automatically loads all ipelets from this directory. Note that the wrapper above does not immediately load the C++ ipelet (using loadIpelet) when the Lua wrapper is loaded by Ipe, but only when the first method of the ipelet is called. This is considered good style.
Your Lua wrapper can include a table with key/value pairs that the C++ code can examine to set parameters or otherwise decide what to do without recompiling the C++ code.
The table is passed as an additional argument to model:runIpelet. You can retrieve the value for a given key using the ipe::IpeletHelper.getParameter method.
Kgon is a minimal ipelet that you can use as the basis for your own development. It defines only a single function, and makes no use of the function argument to run. It does show how to pass parameters from the Lua wrapper to the C++ code.
The Lua wrapper would look like this:
The ipelet must be compiled as a shared library and must be linked with the Ipe library libipe.so. C++ mandates that it must be compiled with the same compiler that was used to compile Ipe. Have a look at the ipelet sources in the Ipe source distribution, and their makefiles for details on compiling them.
The ipelet must be compiled as a DLL and must be linked with the Ipe library ipe.dll. C++ mandates that it must be compiled with the same compiler that was used to compile Ipe. If you use the binary Ipe distribution for Windows, that means you have to use the g++-mingw-w64-x86-64 toolchain. Place the resulting kgon.dll in the ipelets subdirectory, and restart Ipe.
If you write an ipelet in C++, you probably want to link with some existing C++ library or framework such as CGAL, and the loader needs to find this framework when it loads the ipelet.
On MacOS, you would for instance have a setting like this to tell the loader where to find shared libraries:
$ export DYLD_LIBRARY_PATH=$CGAL_DIR/lib
Unfortunately, OSX integrity protection makes it impossible to specify such a setting inside Ipe, in ipe.conf, or in Ipe's Info.plist file.
You can set the environment variable when you call Ipe from the command line, but when starting Ipe from the Finder this does not work.
One clean solution is to make sure the path of the shared library is hard-coded in the ipelet, using otool and install_name_tool on OSX.
A simpler solution is to make a dynamic link like this:
$ ln -s $HOME/CGAL/build/4.13R/lib $HOME/lib
Since $HOME/lib is searched by dlopen, this will work. You can check which paths are searched when Ipe loads an ipelet by setting this environment variable (and running Ipe from the command line):
$ export DYLD_PRINT_LIBRARIES=1