Hi guys, As mentioned in pharo-users, I am refactoring / fixing the implementation of GIFReadWriter, which currently doesn't work correctly. My primary motivation at the start came because I could not open animated GIFs in the World. I am close to having a solution, but could use some input from more experienced Smalltalkers and also those who have experience with ImageReadWriter and subclasses. # Primary Problem # The main problem I'm having: the whole ImageReadWriter infrastructure assumes it will be dealing with single Forms. GIFs, however, are files that can be packed with *many* images, each often having their own metadata about how they should be colored, positioned, and animated. This has presented me with a bit of a conundrum. I don't want to break Image processing functionality in the tools that already exist (chief example here is the "image previews" that display in an inspector when browsing FileReferences). However, I'm not sure what the best path to take is. So I'll explain what I have so far, and then follow up with some possible ideas about how to move forward. # What I have # 1) I have modified GIFReadWriter to actually read all of the sub-images itself (obviating AnimatedGIFReadWriter, which isn't necessary). These images are stored as "frames" (see 2) 2) Created AnimatedImageFrame, a class that wraps an underlying form with additional flags/information about how it should be processed in an animation 3) Created AnimatedImageMorph, which takes a collection of AnimatedImageFrames and cycles through them according to their rules. Also has information about size etc. # What I'm thinking # The above on its own will not work well in the existing Pharo system. What I'm thinking is that we need a class that decorates/subclasses/or is mostly polymorphic with Form to wrap collections of AnimatedImageFrames -- something to serve as the "model" to the AnimatedImageMorph. We could call it AnimatedImage. One advantage (hopefully) would be compatibility with the existing systems that assume all imported images are Forms. Another would be image manipulation like scaling, flipping, etc -- which looping and applying to all underlying frame forms. It would also give us concretely an object that embodies a GIF image the way a single Form embodies any other kind of image. Is there a better way? Should I just stick with AnimatedImageFrame and AnimatedImageMorph and count on other users/implementors to deal with GIFs differently? Thanks at all for any input / suggestions. -- Eric