RE: Re: TortoiseIDiff suggestions

Sorry for the late response to this...

> How about using a factory pattern here for every image type?
> The 'basic' image types can be handled by the IPicture COM object which
> is available on all Windows installations. Tiff then needs GDI+. Icons
> also need their own drawing function because an *.ico file can (and
> usually has) many different depths/sizes in it (as can Tiff, but that's
> not implemented yet). Gif also can have multiple frames (TortoiseIDiff
> can animate gifs).
> Then for the more special image types, we can write separate classes
> which first check for the existence of image libraries (like FreeImage,
> ImageMagic, DevIL, ...) and if they're available handle those types.

I'd been thinking on this subject for the last few days when I remembered something I'd seen in the FreeImage documentation - FreeImage is itself based on a plugin architecture. Why not just make use of that?

I've had a brief look at the FreeImage documentation & it all seems pretty straightforward. Obviously such a usage necessitates having the FreeImage.dll around to support any external plugins, but that's a fairly minor requirement if you ask me - especially if we keep the DLL optional (as we have in the current implementation).

FreeImage also supports multiple images within the same file, as supported by icons, TIFF, DDS (cubemaps), GIF & MNG. It wouldn't be a bad idea to expose this functionality, probably just by following the lead set by the current implementation for supporting icons.

There's also nice bit of example code in the FreeImage documentation detailing a way of enumerating all supported image types and creating relevant file dialog filter strings. This could certainly be useful for the open file dialog.

Also, I was wondering if there might be a smart way to avoid manually assigning all of the supported image types to TortoiseIDiff. What about supporting a special filter "pipeline" for the diff programs? For example:

 "Somefile.ext" -> File extension filter -> Diff Program A -> Diff Program B

In this model, if no exact match were found for its file extension, the file(s) to be diffed would be passed from program to program until one returned a success code. This would allow many formats to be supported without entailing any administration overhead to the user.

Thoughts?

Cheers,
        Will.
Received on Tue Oct 3 01:26:19 2006