Shotwell Plugin-based Postprocessing Tools

[Camilo Polymeris <cpolymeris gmail com>]

Hello again,

after some discussion on my raw development proposal I have decided
that it was too ambitious for the limited time of GSoC, and that I
would leave it to a future date.
In the meanwhile, while working on some shotwell bugs and from reading
the mailing list, I have come up with another proposal. I would
appreciate feedback on the following summary, so I can incorporate it
in the formal proposal to google-melange and in more extensive design
documents.

Shotwell already supports a plugin system for data export (sync to
online services) & slideshow animations[1]. I'd like to add the
ability to postprocess images. The extension to the existing API would
be kept as simple as possible, whenever possible making use of the
current abstractions in the code, while providing some facilities to
easily code new plugins from scratch or interface to external
libraries.
I have some experience with this kind of problem from last year's
gsoc, when I also developed a plugin-based processing system, but for
a scientific application. Also, I have looked how other software's
interfaces are designed, in particular KIPI (KDE imaging plugins [2])
the GIMP[3], and ImageMagick (considered as a possible target).
I have taken some inspiration from them, but I imagine a more simple
system for Shotwell:

1) Tool interface (inheriting from Spit.Pluggable) that would describe
the provided capabilities & process parameters and have a factory
method returning objects implementing the Process interface.
2) Process interface, which would include methods for
 - initializing the process (opportunity to pre-analyze the image and
set default values)
 - reacting on changes to parameter values & updating the preview, and
 - running the process itself.
3) A ToolHost interface, providing access to the shotwell core, plus
feedback & convenience functions.

Images would be passed in memory, but ToolHost will include methods to
save and load from file, to make it easier to add backends to
file-oriented libraries and command-line programs.

The GUI would be based on the existing editing tool window, generated
on the fly based on requested parameters to ensure consistency, and
the registered tools listed next to the built-in ones in the pane
below the each photo. If needed, at a later point a categorized
toolbox can be added, to manage a larger number of tools.
In my opinion, the number of parameters exposed to the user should be
kept to a minimum, both in variety (only a few types) as in number (1
or 2 per tool, maximum), to keep the user interface simple.
Parameter types would be predefined and could include linear ranges
(represented as sliders), booleans (toggles), choices (drop-downs),
colors (color-selector) & some more directly "interactive" ones, like
points (click on image) and image regions (drag a circle or rect on
image).

This year's GSoC project would include designing this interface,
implementing the utility functions, the GUI, plus 1 module including a
few basic tools, probably based on ImageMagick or a similar library.

Some Shotwell users have expressed concerns about adding unnecessary
complexity and dependencies to the program. This will be considered
and most of the functionality constrained to the plugin side, so it
won't affect the core, unless installed.

Looking forward to your comments.

Best regards,
Camilo

[1] http://yorba.org/docs/shotwell/shotwell-plugin-dev/index.htm
[2] http://api.kde.org/4.x-api/kdegraphics-apidocs/libs/libkipi/libkipi/html/index.html
[3] http://developer.gimp.org/api/2.0/index.html