Next Previous Table of Contents
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.
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.
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.
This section describes two problems for which i did not find a satisfacting solution.
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.
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.
As soon as i have time i will try to find a clean solution.
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!
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!