Camilo, thanks for your message. My general feeling about your proposal is that
- it might be more complicated than we want effects to be in Shotwell at this stage in its evolution - it is probably too challenging to implement in a single summer - it's not clear how it will interact with Shotwell's non-destructive editing model I'll elaborate on each of these points below. First, at this stage in Shotwell's evolution I think it might be nice to have a palette of simple effects such as sepia, vignette, matte and so on. The user could click an effect once to apply it a little bit, or several times to apply it more. We could display a number over the effect to indicate the degree to which it's been applied. That would be super easy to use. At some later point I think we might have more general effects controlled by parameters or sliders. For that to work nicely, we'd need to have a scrollable list of effects in a sidebar (like in Lightroom or Aperture). I think we'd also want to move the existing editing tools into the sidebar, and display metadata information there too (see http://redmine.yorba.org/issues/1918). That's how I see Shotwell's interface evolving in the long term, but I think we won't get there in time for a summer of code project this summer. I don't think we ever want effects in Shotwell to be able to operate at a certain point in a photo or on a photo region as you've suggested. To me, that's the domain of editors such as GIMP. Shotwell should interact nicely with such programs, but I don't think we need those capabilities in Shotwell. One challenge with implementing effects as plugins is that Shotwell is non-destructive. As you probably know, when you make edits in Shotwell nothing changes on disk; Shotwell simply remembers your edit parameters. Every time you open a photo in Shotwell, it applies your edits on the fly. If we implement effects as plugins, then they could be applied on the fly too. But now what happens if I've used an effect to edit a photo, and then I uninstall the effect and open the photo? Shotwell won't be able to apply the effect since its code will not be present. We could solve this by saying that effects are destructive, but would be disappointing - I'd like to be able to undo an effect after applying it. So we might just have to accept that if you uninstall an effect, you can't open any photo that it was applied to. (Before too long, we want to modify Shotwell so that it writes all edits to photo files on the disk while still keeping the original file - this is http://redmin e.yorba.org/issues/1798. If we have that, then if an effect is uninstalled at least you would still have the modified photo to work with.) Another concern here is this: what if an effect plugin gets updated to a newer version which uses a different algorithm for applying the effect? Then if I open a photo which uses the effect, suddenly it will look different than it did before. Is this OK? Or do we need a version number for each effect? These are all things to think about, but all of this is deep enough that I think it may be best left to the core team rather than implemented as a summer project. I don't want to be discouraging . You could think through all these issues, study the code to convince yourself that this is doable in a summer, and produce a detailed proposal that describes both how the user interface will work and the architectural changes you plan to make in order to implement this. If you do all that, we'll certainly be interested to read it and will be open-minded about the project if it seems feasible. But if you're unsure, I suggest that you look through the Shotwell ticket list (we have over 800 bugs and feature requests!) for ideas which would not require deep changes to the Shotwell core and which would be more easily approached in a summer timeframe. Cheers - adam On Wed, Mar 28, 2012 at 3:12 PM, Camilo Polymeris <[email protected]> wrote: > 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 > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
