Next Previous Table of Contents


Internals

Configuration Files

All configuration files are stored in $HOME/.babygimp. Currently the are four such files:

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.

I don't describe the file formats here since there should be no need to edit these filese manually.

Security Considerations

Since the config file contains a shell command (the help browser) it is a possible security hole. 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.

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.

Plugins

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.

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

"cat $tmpdir/plugin_input.xpm | $command > $tmpdir/plugin_output.xpm"

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.

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.

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).

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.

Hacks

This section describes two problems for which i did not find a satisfacting solution.

Note: 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!


Next Previous Table of Contents