NAME

Gimp::Extension - Easy framework for Gimp-Perl extensions

SYNOPSIS

  use Gimp;
  use Gimp::Extension;
  podregister {
    # your code
  };
  exit main;
  __END__
  =head1 NAME

  function_name - Short description of the function

  =head1 SYNOPSIS

  <Image>/Filters/Menu/Location...

  =head1 DESCRIPTION

  Longer description of the function...

DESCRIPTION

This module provides all the infrastructure you need to write Gimp-Perl extensions.

Your main interface for using Gimp::Extension is the podregister function. This works in exactly the same way as "PODREGISTER" in Gimp::Fu, including declaring/receiving your variables for you, with a few crucial differences. See below for those differences.

Before control is passed to your function, these procedures are called:

  Gimp::gtk_init; # sets up Gtk2, ready for event loop
  Gimp->extension_ack; # GIMP hangs till this is called
  Gimp->extension_enable; # adds an event handler in Glib mainloop for
                          # GIMP messages

Your function will then either proceed as if it were a plugin, or call the Glib/Gtk2 mainloop:

  Gtk2->main;

Values returned by your function will still be returned to a caller, as with a plugin.

One benefit of being an extension vs a plugin is that you can keep running, installing temporary procedures which are called by the user. When they are called, the perl function you have registered will be called, possibly accessing your persistent data or at least benefiting from the fact that you have already started up.

Another benefit is that you can respond to events outside of GIMP, such as network connections (this is how the Perl-Server is implemented).

Additionally, if no parameters are specified, then the extension will be started as soon as GIMP starts up.

If you need to clean up on exit, just register a callback with Gimp::on_quit. This is how Perl-Server removes its Unix-domain socket on exit.

PODREGISTER DIFFERENCES

The podregister function here is different from in Gimp::Fu in that parameters and return values are not added for you, and your function name will not be changed but passed to GIMP verbatim.

The run_mode is passed on to your function, rather than being stripped off as with Gimp::Fu.

FUNCTIONS AVAILABLE TO EXTENSIONS

These are all exported by default.

podregister

As discussed above.

add_listener

This is a convenience wrapper around Glib::IO->add_watch. It takes parameters:

$listen_socket

This will be an IO::Socket subclass object, a listener socket. When it becomes readable, its accept method will be called.

\&handler

This mandatory parameter is a function that is installed as the new connection's Glib handler. Its parameters are: $fd, $condition, $fh - in Glib terms, the file handle will be registered as the "data" parameter. When it returns false, the socket will be closed.

\&on_accept

This optional parameter will, if defined, be a function that is called one time with the new socket as a parameter, possibly logging and/or sending an initial message down that socket.

register_temp

This is a convenience wrapper around Gimp->install_temp_proc, supplying a number of parameters from information in the extension's POD. The registration will only happen when the extension's on_run callback is called. It takes parameters:

$proc_name

The name of the new PDB procedure.

$blurb

$help

$menupath

$imagetypes

$params

$retvals

All as per "Gimp->install_procedure" in Gimp.

\&callback

TODO

 =head1 TEMPORARY PROCEDURES
 =head2 autosave_configure - blurb text

 Longer help text.

 =head3 PARAMETERS

 # gets interpolated vars per Gimp::Fu
 podregister_ui 'autosave_configure' => sub { ... };

 podregister will have interpolated vars too, and
 add vars based on menupath, etc
 menupath <Autostart> - die if get any params/retvals

AUTHOR

Ed J

SEE ALSO

perl(1), Gimp, Gimp::Fu.

cpanm Gimp

perl -MCPAN -e shell
install Gimp