Creating Tux Paint Magic Tool Plugins

Copyright 2007-2007 by Bill Kendrick and others
New Breed Software

bill@newbreedsoftware.com
http://www.tuxpaint.org/

July 5, 2007 - July 27, 2007


Overview

Beginning with version 0.9.18, Tux Paint's 'Magic' tools were converted from routines that lived within the application itself, to a set of 'plugins' that are loaded when Tux Paint starts up.

This division allows more rapid development of 'Magic' tools, and allows programmers to create and test new tools without needing to integrate them within the main Tux Paint source code. (Users of more professional graphics tools, such as The GIMP, should be familiar with this plugin concept.)


Prerequisites

Tux Paint is written in the C programming language, and uses the Simple DirectMedia Layer library ('libSDL', or simply 'SDL'). Therefore, for the moment at least, one must understand the C language and how to compile C-based programs. Familiarity with the SDL API is highly recommended, but some basic SDL concepts will be covered in this document.


Interfaces

Those who create 'Magic' tool plugins for Tux Paint must provide some interfaces (C functions) that Tux Paint may invoke.

Tux Paint utilizes SDL's "SDL_LoadObject()" and "SDL_LoadFunction()" routines to load plugins (shared objects files; e.g., ".so" files on Linux or ".dll" files on Windows) and find the functions within.

In turn, Tux Paint provides a number of helper functions that the plugin may (or sometimes is required to) use. This is exposed as a C structure (or "struct") which contains pointers to functions and other data inside Tux Paint. A pointer to this structure gets passed along to the plugin's functions as an argument when Tux Paint invokes them.

Plugins should #include the C header file "tp_magic_api.h", which exposes the 'Magic' tool plugin API. Also, when you run the C compiler to build a plugin, you should use the command-line tool "tp-magic-config" to get the appropriate compiler flags (such as where the compiler can find the Tux Paint plugin header file, as well as SDL's header files) for building a plugin.

The C header file and command-line tool mentioned above are included with Tux Paint — or in some cases, as part of a "Tux Paint 'Magic' Tool Plugin Development package".

'Magic' tool plugin functions

'Magic' tool plugins must contain the functions listed below. Note: To avoid 'namespace' collisions, each function's name must start with the shared object's filename (e.g., "blur.so" or "blur.dll" would have functions whose names begin with "blur_"). This includes private functions (ones not used by Tux Paint directly), unless you declare those as 'static'.

Common arguments to plugin functions:

Here is a description of arguments that many of your plugin's functions will need to accept.

Required plugin functions:

Your plugin is required to contain, at the least, all of the following functions.

Note: Remember, your plugin's function names must be preceded by your plugin's filename. That is, if your plugin is called "zoom.so" (on Linux) or "zoom.dll" (on Windows), then the names of your functions must begin with "zoom_" (e.g., "zoom_get_name(...)").

Plugin "housekeeping" functions:
  • Uint32 api_version(void)
    The plugin should return an integer value representing the version of the Tux Paint 'Magic' tool plugin API the plugin was built against. The safest thing to do is return the value of TP_MAGIC_API_VERSION, which is defined in "tp_magic_api.h". If Tux Paint deems your plugin to be compatible, it will go ahead and use it.

    Note: Called once by Tux Paint, at startup. It is called first.
  • int init(magic_api * api)
    The plugin should do any initialization here. Return '1' if initialization was successful, or '0' if not (and Tux Paint will not present any 'Magic' tools from the plugin).

    Note: Called once by Tux Paint, at startup. It is called first. It is called after "api_version()", if Tux Paint believes your plugin to be compatible.
  • int get_tool_count(magic_api * api)
    This should return the number of Magic tools this plugin provides to Tux Paint.

    Note: Called once by Tux Paint, at startup. It is called after your "init()", if it succeeded.

  • char * get_name(magic_api * api, int which)
    This should return a string containing the name of a magic tool. This will appear on the button in the 'Magic' selector within Tux Paint.

    Tux Paint will free() the string upon exit, so you should wrap it in a C strdup() call.

    Note: Called once for each Magic tool your plugin claims to contain (by your "get_tool_count()").

  • SDL_Surface * get_icon(magic_api * api, int which)
    This should return an SDL_Surface containing the icon representing the tool. (A greyscale image with alpha, no larger than 40x40.) This will appear on the button in the 'Magic' selector within Tux Paint.

    Tux Paint will free ("SDL_FreeSurface()") the surface upon exit.

    Note: Called once for each Magic tool your plugin claims to contain (by your "get_tool_count()").

  • char * get_description(magic_api * api, int which)
    This should return a string containing the description of a magic tool. This will appear as a help tip, explained by Tux the Penguin, within Tux Paint.

    Tux Paint will free() the string upon exit, so you should wrap it in a C strdup() call.

    Note: Called once for each Magic tool your plugin claims to contain (by your "get_tool_count()").

  • int requires_colors(magic_api * api, int which)
    Return a '1' if the 'Magic' tool accepts colors (the 'Colors' palette in Tux Paint will be available), or '0' if not.

    Note: Called once for each Magic tool your plugin claims to contain (by your "get_tool_count()").

  • void shutdown(magic_api * api)
    The plugin should do any cleanup here. If you allocated any memory or used SDL_Mixer to load any sounds during init(), for example, you should free() the allocated memory and Mix_FreeChunk() the sounds here.

    Note: This function is called once, when Tux Paint exits.

Plugin event functions:
  • void set_color(magic_api * api, Uint8 r, Uint8 g, Uint8 g)
    Tux Paint will call this function to inform the plugin of the RGB values of the currently-selected color in Tux Paint's 'Colors' palette. (It will be called whenever one of the plguin's Magic tools that accept colors becomes active, or the user picks a new color while such a tool is currently active.)

  • void click(magic_api * api, int which, SDL_Surface * snapshot, SDL_Surface * canvas, int x, int y, SDL_Rect * update_rect)
    The plugin should apply the appropriate 'Magic' tool on the 'canvas' surface. The (x,y) coordinates are where the mouse was (within the canvas) when the mouse button was clicked.

    The plugin should report back what part of the canvas was affected, by filling in the (x,y) and (w,h) values in 'update_rect'.

    The contents of the drawing canvas immediately prior to the mouse button click is stored within the 'snapshot' canvas.

  • void drag(magic_api * api, int which, SDL_Surface * snapshot, SDL_Surface * canvas, int ox, int oy, int x, int y, SDL_Rect * update_rect)
    The plugin should apply the appropriate 'Magic' tool on the 'canvas' surface. The (ox,oy) and (x,y) coordinates are the location of the mouse at the beginning and end of the stroke. Typically, plugins that let the user "draw" effects onto the canvas call the Tux Paint 'Magic' tool plugin "line()" helper function. (See below).

    The plugin should report back what part of the canvas was affected, by filling in the (x,y) and (w,h) values in 'update_rect'.

    Note: The contents of the drawing canvas immediately prior to the mouse button click remains as it was (when the plugin's "click()" function was called), and is still available in the 'snapshot' canvas.

  • void release(magic_api * api, int which, SDL_Surface * snapshot, SDL_Surface * canvas, int x, int y, SDL_Rect * update_rect)
    The plugin should apply the appropriate 'Magic' tool on the 'canvas' surface. The (x,y) coordinates are where the mouse was (within the canvas) when the mouse button was released.

    The plugin should report back what part of the canvas was affected, by filling in the (x,y) and (w,h) values in 'update_rect'.

    Note: The contents of the drawing canvas immediately prior to the mouse button click remains as it was (when the plugin's "click()" function was called), and is still available in the 'snapshot' canvas.

Tux Paint Functions

Tux Paint provides a number of helper functions that plugins may access via the "magic_api" structure, sent to all of the plugin's functions (see above).


Compiling

Linux and other Unix-like Platforms

Use the C compiler's "-shared" command-line option to generate a shared object file (".so") based on your 'Magic' tool plugin's C source code.

Additionally, use the "tp-magic-config --cflags" command, supplied as part of Tux Paint, to provide additional command-line flags to your C compiler that will help it build your plugin.

As a stand-alone command, using the GNU C Compiler and BASH shell, for example:

gcc -shared `tp-magic-config --cflags` my_plugin.c -o my_plugin.so

Note: The characters around the "tp-magic-config" command are a grave/backtick/backquote ("`"), and not an apostrophe/single-quote ("'"). They tell the shell to execute the command within (in this case, "tp-magic-config ..."), and use its output as an argument to the command being executed (in this case, "gcc ...").

A snippet from a more generalized Makefile might look like this:

CFLAGS=-Wall -O2 $(shell tp-magic-config --cflags)

my_plugin.so: my_plugin.c    $(CC) -shared $(CFLAGS) -o $@ $<

You may then install it globally into: /usr/lib/tuxpaint/plugins/ or /usr/local/lib/tuxpaint/plugins/ (depending on how Tux Paint was installed).

Or install it locally (for the current user only) into: ~/.tuxpaint/magic/
(FIXME: As of 2007-07-27, Tux Paint does not look here yet!)

Windows

TBD

Mac OS X

TBD


Creating plugins with multiple effects

TBD

Example Code

TBD

Summary and contact info TBD.