1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<refentry id="plugin-proxy-overview" revision="$Id: plugin-proxy-overview.xml 20682 2017-12-18 18:39:00Z yeti-dn $">
<refmeta>
<refentrytitle>Plug-in Proxy Overview</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>Gwyddion</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Plug-in Proxy Overview</refname>
<refpurpose>
Overview of <application>Gwyddion</application> plug-ins and the plugin-proxy module
</refpurpose>
</refnamediv>
<refsect1>
<title>Plug-ins Overview</title>
<para>
Plug-ins are external programs that can be executed by <application>Gwyddion</application>
to either perform some operation on the data or to read or write
data in a third-party file format.
</para>
<para>
Generally it is preferable to extend <application>Gwyddion</application> functionality by
modules, because modules are dynamic libraries linked directly
to <application>Gwyddion</application> at run-time allowing much more versatile interaction
with the application, and they are also faster (for the same reason).
For example, plug-ins generally cannot make use of existing <application>Gwyddion</application>
data processing functions and cannot modify data in-place, a new
window is always created for the result.
Programming of modules is also no harder than programming of plug-ins,
maybe it is even easier (assuming you know C).
</para>
<para>
They are however two reasons to use plug-ins:
<itemizedlist>
<listitem>
Instability. A crash in a module is a crash in <application>Gwyddion</application>
because modules, once loaded, become part of the application.
When a plug-in fails, one gets garbage or nothing instead of
data, but it does not affect the application.
</listitem>
<listitem>
Licensing. Since modules link with <application>Gwyddion</application> they are derived
works of it and thus they have to be licensed under GNU General
Public License, if they are to be distributed. The plug-in
interface was on the other hand designed specifically to allow
plug-ins to be independent works and thus not bound by GNU GPL
(you are of course still encouraged to use GNU GPL for your
plug-ins).
The interface consists only of a small set of command line
arguments and a very simple data file format used for data
exchange.
</listitem>
<listitem>
Testing. While module unloading and reloading is theoretically
possible, it is not implemented. Thus one has to quit and restart
<application>Gwyddion</application> for changes in a module to take effect. Plug-ins are
separate programs, so they are run in whatever state they currently
are each time they are used.
</listitem>
<listitem>
Language issues. <application>Gwyddion</application> currently has only C API.
If you already have your data processing routines written in
FORTRAN, Java, Ruby, Delphi, or whatever, you may find easy to make
a plug-in from them, while conversion to a module can require
substantial changes and/or rewrite to C.
</listitem>
</itemizedlist>
</para>
</refsect1>
<refsect1>
<title>Plug-in Proxy</title>
<para>
The capability to use plug-ins is not a built-in <application>Gwyddion</application> feature,
instead it is provided a by a smart module called plug-in proxy.
With the small exception there is a dedicated directory for plug-ins
defined directly in <application>Gwyddion</application>, the plug-in proxy module is in no way
privileged or otherwise special.
It can be removed and/or other plug-in proxies can be added and
happily coexist with the current one.
</para>
<para>
When the plug-in proxy module registeres self, it scans the plug-in
directories, requests information from the plug-ins it finds and passes
the information as its own features.
Likewise when it is run to process some data it executes
the appropriate plug-in to process it and passes the result back to
<application>Gwyddion</application>. All plug-in features thus look as plug-in proxy features
to <application>Gwyddion</application>, as you can see yourself in the Module Browser.
</para>
<para>
FIXME: More to be said.
</para>
</refsect1>
</refentry>
|
