Re: TortoiseIDiff suggestions

Ivan-Assen Ivanov wrote:
>> >>> Finally, we could use more image formats. We use
>> >>> heavily TGA and DDS.
>> > Another, less involving option would be to expose a
>> > basic plugin API for TortoiseIDiff to expose. This
>> > would allow for the support of all of the esoteric
>> > formats out there without causing any additional
>> > overhead (beyond implementing the plugin management)
>> > to the rest of the TSVN project.
>>
>> I basically like that idea. But wouldn't it be a little steep for this
>> little application to handle all those different file formats? An
>> interface towards for example ImageMagick might be more appropriate..?
>
> Including the whole of ImageMagick would make this little application
> probably larger than the rest of TortoiseSVN combined.
>
> A generic plugin interface introduces tons of complexity both for
> developers and users. How are plugins installed into a system? How are
> they distributed? How do plugins "claim" an image to be their own?
> When a 3rd-party plugin crashes, will the user complain to the author,
> or will he come to the TortoiseSVN mailing list? Will developers
> bother to produce 64-bit DLLs for the plugins?

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.

Suggestion for the interface of such an image handler:
IImageHandler
// resets the enumeration of image types which can be handled
bool IImageHandler::StartEnumImageTypes()
// returns an image type in 'extension'. If false is returned, the
// enumeration is finished
bool IImageHandler::EnumImageTypes(TCHAR * extension)

// returns true if the image can be handled
bool IImageHandler::CanHandleImageType(const TCHAR * extension)

// for the next interface functions, please refer to the CPicture class
// we already have
bool IImageHandler::LoadImage(const TCHAR * path)
bool IImageHandler::Show(HDC hDC, RECT rect)
bool SetInterpolationMode(InterpolationMode ip)
float IImageHandler::GetHorizontalResolution()
float IImageHandler::GetVerticalResolution()
UINT IImageHandler::GetHeigth()
UINT IImageHandler::GetWidth()
UINT IImageHandler::GetColorDepth()
UINT IImageHandler::GetNumberOfFrames()
long IImageHandler::SetActiveFrame()

And since Hans-Emil Skogh wants to add some other image comparison
functions and needs the image binary data:

BitmapData* IImageHandler::GetBitmapData()
bool IImageHandler::ReleaseImageData()

Then, CPicture would implement the factory pattern and create the
correct handler for an image type, then use that handler.
We could even make it so that all the methods in CPicture don't have to
change at all (but of course some methods would have to be added).

Comments?

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org