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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Babygimp Manual - Internals</title>
<meta name="GENERATOR" content="amaya V5.0">
</head>
<body bgcolor="#FFFFFF">
<p><a href="preferences.html">Nex</a>t <a href="bugs.html">Previous</a> <a
href="index.html"> Table of Contents</a></p>
<hr>
<h1>Internals</h1>
<h2>Configuration Files</h2>
<p>All configuration files are stored in $HOME/.babygimp. Currently the are
four such files:</p>
<ul>
<li>$HOME/.babygimp/babygimp.config contains those options which are set in
the options dialog.</li>
<li>$HOME/.babygimp/bookmarks contains the bookmarks of the file
browser.</li>
<li>$HOME/.babygimp/importers and $HOME/.babygimp/exporters contain the
shell commands which are invoked when image formats other than xpm are
loaded or saved.</li>
</ul>
<p>In addition babygimp will create the subdirectory $HOME/.babygimp/plugins
and $HOME/.babygimp/tmp (for temporary files when using plugins). In
$HOME/.babygimp/plugins you will also find backups of changed plugins.</p>
<p>I don't describe the file formats here since there should be no need to
edit these filese manually.</p>
<h2>Security Considerations</h2>
<p>Since the config file contains a shell command (the help browser) it is a
possible <strong>security hole</strong>. The same holds for plugins,
importers and exporters. Therefore Babygimp will not read the config file or
plugins if others than the user (or root) has write permission. I am however
not sure wheather this is safe on systems where users can ``donate'' files to
other users.</p>
<p>Babygimp also tries to detect corrupted plugin files but you should not
bank on this. It is always a good idea to check the shell command to be
executed using the info function of the plugin dialog.</p>
<h2>Plugins</h2>
<p>Each plugin is internally represented by a plugin object which contains a
shell command string and some informations about the formal parameters. When
the plugin is applied the shell command string is parsed and the formal
parameters are replaced by their values.</p>
<p>If the plugin is a (region) filter, the image (region) is stored to the
file $HOME/.babygimp/tmp/plugin_input.xpm. Then Babygimp invokes the shell
command</p>
<p>"cat $tmpdir/plugin_input.xpm | $command >
$tmpdir/plugin_output.xpm"</p>
<p>where $tmpdir is $HOME/.babygimp/tmp and $command is the substituted shell
command. Finally Babygimp tries to read the file
$HOME/.babygimp/tmp/plugin_output.xpm.</p>
<p>Of course it would be (slightly) more efficient to use double pipes
instead of temporary files. However this might also lead to subtle blocking
problems when the external program does not buffer its output. So for
simplicity i choosed the primitive approach. Creators would not raise this
problem (only a single pipe), but in order to keep the plugin mechanism
uniform i decided that also in this case temporaries are used.</p>
<p>When i started to write the plugin mechanism i first thought that it would
be difficult to find a plugin file format that is flexible enough but still
easy to parse. But this problem had a trivial solution: Each plugin is
internally represented as an object of class Plugin. The contents of a plugin
file is just the output of Data::Dumper, applied to a Plugin object. This way
it is possible to read plugin files simply using Perls do() function (for
security reasons this is done in an extra name space).</p>
<p>Babygimp also tries to detect corrupted plugin files but you should not
bank on this. It is always a good idea to check the shell command to be
executed using the info function of the plugin dialog.</p>
<h2>Hacks</h2>
<p>This section describes two problems for which i did not find a
satisfacting solution.</p>
<ul>
<li><a name="Communicat">Communication between different instances of
Babygimp:</a>
<p>This is a terrible hack. First, Babygimp checks whether another
instance of Babygimp is already running (via somthing like ps --User
$ENV{$USER} | grep $progname). This is terrible since the implementation
of the ps command is quite different on different systems, so it may not
work on some systems.</p>
<p>If no instance is found Babygimp starts in normal mode. Otherwise,
Babygimp creates a named pipe ~/.babygimp/babygimp.fifo and writes the
first command line argument to this fifo. The already running instance of
Babygimp periodically checks wheather the fifo ~/.babygimp/babygimp.fifo
exists. In this case Babygimp reads the first line and tries to load the
specified file into the clipboard.</p>
<p>As soon as i have time i will try to find a clean solution.</p>
<p></p>
</li>
<li>Loading images:
<p>This is also a terrible hack. Images are loaded using Tk::Photo. The
problem is how to detect transparent pixels, since Photo->get()
returns (0,0,0) on transparent pixels (why not undef?!:-(). However the
Photo method allows to specify a background. So Babygimp creates two
Photo objects for each loaded image with different backgrounds. Than
Photo->get() will return the different background colors for
transparent pixels, so they can be detected. Of course this is highly
unsatisfactory and inefficient. Any better solution would be highly
appreciated!</p>
</li>
</ul>
<p></p>
<p><span style="font-weight: bold">Note:</span> You may wish to have a look
at the code. But Larry Walls writes in his book that the experts won't laugh
when they see a beginners code!</p>
<p></p>
<hr>
<p><a href="preferences.html">Next</a> <a href="bugs.html">Previous</a> <a
href="index.html">Table of Contents</a></p>
<p></p>
<p></p>
</body>
</html>
|
