Latest News.. Checkout the whitepaper
on InterActor that includes information on IAMovie to code presentations and animations.
In a time far away - about fifteen years now - the first version of InterActor was produced as part of a research project. It had many novel features, and was integrated with an extremely interesting programming language.
As a research project it was a great success, demonstrating all that we had hoped for. But, of course, we did not become the millionaires we deserved.
While working on the graphical tools for The Alchemist I have been continually frustated with Java Swing. Don't get me wrong here, I think they did a good job, and if I had wanted to produce an application that demonstrated Java Swing functionality I'm confidant I could have come up with something.
But, I didn't want to have to think of what I could achieve with Java Swing. I wanted to achieve a specific functionality, and it seemed to me I was forever prodding Swing with long sticks.
Rather than spend weeks refining my Swing expertise to approximate my objectives. I have resolved to re-implement InterActor using Java 2D. This is a long-term project, but one that should be eased with java dynamic memory and build times in seconds rather than the Object Pascal and alpha version C++ with hour long builds of the original.
The plan is to develop InterActor as the graphical environment to support the Alchemist and also to implement a CTCDraw graphical drawing package.
I do not have the time to describe the full InterActor model at present, but I will mention perhaps the key point.
This idea is so brilliant that it should no longer be confined to the Syquest cartridges of the original project.
The IASlot is a key structure that binds content and context. Conventionally, sub-windows,
sub-views, sub-components, whatever, are in a strict parent-child hierarchy. This seems fine for
most display purposes. Unfortunately it prevents two possibilities, firstly that a single element
could exist in more than one place, and secondly, an identity to represent what has to happen in order
for an Interface to communicate - state change.
Sure, there are Model-View-Controller (MVC) patterns that address some of this, but this is not always simplifying.
Here is a java snippet of IASlot definition:
public class IASlot {
protected IAShape m_context;
protected IASlot m_prevContent;
protected IASlot m_nextContent;
protected IAShape m_content;
protected IASlot m_prevContext;
protected IASlot m_nextContext;
protected int m_locx;
protected int m_locy;
protected IATransition m_transition;
}
The most significant thing about the InterActor model is that it is designed to specifically represent state change.
For certain, a consistent rendering model is necessary in order to be able render any interface at all, but far too much emphasis has been placed on this aspect of graphical user interfaces.
The MVC approach is useful in that structures are built that allow a user interface to be updated as a result of some data structure update. But effecting the state change in the interface can still be an awkward task.
The Java Swing Card Layout does address the problem to some extent, but is not a general solution.
Maybe most interesting is the development of DHTML in attempting to provide more functional interactions. The rendering of an HTML element has to be modified by structural change in order to change its appearance.
Yes they do. And there is nothing that can be achieved with InterActor that could not be achieved with conventional tools - albeit with considerably more effort.
It is simply the case that the InterActor model is better.