PluginProgramming.docu 2.13 KB
Newer Older
Jan Möbius's avatar
 
Jan Möbius committed
1
/*! \page pluginProgramming Plugin Programming
Mike Kremer's avatar
Mike Kremer committed
2
3
4
5
 *
 * \section quickref Quick references:
 * - \ref plugin_sec
 * - \ref plugin_prog_sec
Mike Kremer's avatar
Mike Kremer committed
6
 * - \ref geometryData
Mike Kremer's avatar
Mike Kremer committed
7
8
9
10
11
 * \section tuts Tutorials
 * - \ref ex1
 * - \ref ex1b
 * - \ref ex2
 *
Jan Möbius's avatar
 
Jan Möbius committed
12
13
 * \section plugin_sec Plugin Basics
 * 
Mike Kremer's avatar
Mike Kremer committed
14
 * As mentioned above Openflipper is a plugin based system. It uses the qt plugin implementation to
Jan Möbius's avatar
 
Jan Möbius committed
15
16
17
18
19
20
21
22
23
24
 * load and unload plugins at runtime. Every algorithm should be added as one of these plugins. 
 * 
 * The plugins have to be created as .so (or under windows : .dll) files which should be symlinked or 
 * copied to the Plugin subfolder. OpenFlipper distinguishes between 32/64-bit plugin versions and
 * max or dbg (release/debug) versions. So the compiled plugins have to reside in the right subdir of
 * Plugins. The Plugins are loaded on startup of the application (they may also be loaded at runtime 
 * later). 
 * 
 * \section plugin_prog_sec Plugin programming
 * The interface between the core and the plugins is managed via simple interfaces based on the signal/slot
Dirk Wilden's avatar
Dirk Wilden committed
25
 * metaphor of qt. Your plugins have to be derived from these interfaces. You dont have to implement
Jan Möbius's avatar
 
Jan Möbius committed
26
27
28
29
30
31
32
 * all functions or signals of the interfaces you include. This has only to be done for the BaseInterface 
 * which must be implemented by every plugin. See the BaseInterface Documentation for details.
 * 
 * Unimplemented functions will be left unconnected from the core and wont have any impact on the applications
 * speed or stability. As stated above, every plugin has to be derived from the BaseInterface. This is the
 * basic factory which makes the core aware of the plugin. The name and the description of the plugin is 
 * exported via the baseinterface. The initialization of each plugin is done via this interface too.
33
 * See \ref dataFlow for an overview of OpenFlipper's data flow and interface function calls.
Jan Möbius's avatar
 
Jan Möbius committed
34
35
36
37
 * 
 * After this interface of the plugin is sucessfully processed all other interfaces will be initialized
 * and connected to the core. For details about the individual interfaces see their documentation. 
 * \ref interfaces
38
 *
Mike Kremer's avatar
Mike Kremer committed
39
 * \section geometryData Handling geometry data whithin a plugin
Jan Möbius's avatar
 
Jan Möbius committed
40
 */