So animated .gifs and .png can be easily created with RW software? This would be cool. Might need another section in the gallery for animated pictures, like animated emoticons, logos, web buttons, and other "simple" graphics that people create, in addition to the cursor and icon sections.
The evolution of Open and Save
The evolution of Open and Save
Published by Vlasta on August 1st 2011.
This is not my typical post. While it is loosely tied to RealWorld software, it addresses a possible evolution of the document opening and saving architecture (or, if you prefer, importing and exporting) in any complex software of the "editor" kind.
1. Monolithic system
Editors usually start simple, supporting their own proprietary file format. The object that holds the data (usually called Document or Model) is able to serialize them to a file and later read the file and restore the data.
There is nothing wrong with this architecture and it is perfectly suitable for simple editors. But if an editor becomes at least a bit successful, new requirements emerge...
2. Using codec plug-ins
Supporting multiple formats for exporting an importing of data is usually pretty high on the priority list. The software architect decides to split the previously monolithic object into 3 new ones. The central part still holds the edited data, while the other 2 handle the loading and saving tasks.
In an ideal case, the interface between the central object and the decoders and encoders is made public and the functionality of the editor can be extended by codec plug-ins.
3. Multiple editors in one package
As the editor grows, it may become necessary to support multiple document types. For an image editor, the types could be raster image, vector image, or animation. For a IDE, they could be plain text, php code, image, etc.
At this point, the previously simple and clear architecture is starting to fall apart. We have multiple editors and they look independent on the picture, but there are not.
Consider for example the .xbm image format. While it describes an image, it is also a valid C code and it can be opened in a plain text editor. Another example could be the .gif image format. A .gif can be animated. Should it be opened with a still image editor or with an animation editor?
4. Shared codecs
The architecture in the previous step assumed each editor has its own codecs. The .xbm, and .gif examples demonstrated conflicts caused by that architecture. We need to be looking for solutions. Sharing the codecs is one of them.
While in the previous architecture we would need 2 separate codecs for a .gif file format (one that would be used with a still image editor and another one for the animation editor), this revised architecture only needs one. But the codec must be much smarter. It must be able to decide whether to open the .gif file as an animation or not.
The codec must be aware that there are N possible editors it can use. This could be a problem. The editor we are talking about right now is quite complex (consider for example Eclipse or Visual Studio and, of course, RealWorld apps). Not only do these complex editors support plug-ins for codecs, they may also support plug-ins for the actual editors (let's call the objects document type plug-ins).
This means that a codec plug-in must be aware of the possible document types it can create when decoding a file. Simultaneously, it is unable to be aware of them, because they are also plug-ins and they may be installed at user's will.
The problem here is that there are too many dependencies. Each change influences too many neighbor plug-ins.
5. Using Builders to reduce dependencies
The way to reduce the dependencies between a codec and a document type plug-ins is by separating them by a formalized but flexible interface.
Separating the encoders is relatively easy. The document types and the encoders can simply announce what information needs to be saved (doc-types) and can be saved (encoders). Finding the best match and eventually letting users override the default choice is manageable.
Dealing with decoders is trickier. There must be a mechanism that lets a decoder create documents without knowing what document types are available. This can be arranged by creating specialized builder objects.
Each builder implements one or more interfaces and is able to create one type of document. Imagine a builder for an Animation document type. It may implement an interface for "animation building", but it may also implement an interface for "image building". This means that a .jpg decoder that requires a builder with "image building" capabilities can be used with the Animation builder to open .jpg files as trivial 1-frame animations.
Is this a big deal?
I believe, it is. The last mentioned architecture allows an editing software to grow while still remaining manageable from the engineering point of view. Most software architects would agree that the number of interconnections within a software determines how difficult it is to further develop and maintain that software. Every reduction in complexity counts and moves the point of breakdown (let's call it complete redesign) further into the future.
Is this the only way?
Is it really necessary to have multiple editors in one package? I am not sure, but it seems that way.
Since I am involved in the image editing field, let's look at animations in Photoshop and GIMP.
Photoshop is known to be an image/photo editor, but it also supports animations. While the user interface for animations is not visible by default, you can enable it for any image. This means that every image opened in Photoshop is actually opened as an "animation". Hence Photoshop is not an image editor, but an animation editor - a more powerful thing that is harder to develop and maintain.
GIMP on the other hand is just an image/photo editor. It is able work with animation via a hack - the user must forget how layers work an he must imagine that layers are actually frames. Oh, well.
So, there are alternatives to having multiple editors under one roof. Are these approaches better? That's for you to decide.
The state of RealWorld apps
Future versions of RW apps will be based on the last architecture. This will open the way to proper support of animations in the future.
Recent comments
This is one of the steps required to support animations, I am not there yet 
.
I am considering another section of the library, but I also think creating a general-purpose image/animation library would not work. DeviantArt, Flickr and many more are already doing it and they are good at it. I would need something unique...
Anonymous