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 _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
