PackageDescription: WS-Pollock(Bundle)

WS - Pollock

Last published: June 2, 2007 by 'jamesr'

NOTE: This is an obsolete version of Pollock, but it is the version required by the most recent available WithStyle package.

JR: 5/4/07

Pollock is the next generation VisualWorks GUI Framework.

[This version now requires that a version of VisualWorks 7.1]

The goals of this new Framework are really quite simple. Make a GUI Framework that maintains all of the goals of the current VisualWorks GUI, that is flexible and capable enough to see us forward for at least the next decade.
To this overall goal we add these less concrete goals too.
- The new GUI Framework must be more accessible to both novice and expert developers.
- The new GUI Framework must be more modular.
- The new GUI Framework must be more adaptable to new looks and feels.
- The new GUI Framework must have comprehensive unit tests (Yes, I'm an XP supporter).
Finally, and most importantly:
- The new GUI Framework must be developed out in the open.
The name for this new Framework, Pollock came during the review of other VisualWorks GUI frameworks, most directly, Van Gogh. Its just a way of saying we need a new, modern abstraction.

The guiding metaphor: Panes with Frames - Artists and Agents:

As an XP supporter, we start with a metaphor.
A Pane at its simplest is akin to the existing VisualComponent. A Pane may have subpanes. There is be an AbstractPane class. The Window is also a kind of Pane, but because we don't plan to re-write the whole world, it will remain in it's own hierarchy. Also, the Screen becomes in effect the outermost Pane. Other than that, all widgets will be subclassed in one way or another from the AbstractPane.
The Frame has a couple of pieces, but in general can be thought of as that which surrounds a Pane. One part of a Frame is its layout. That is like our existing layout classes, that which defines where it sits in the Pane that encloses it. It optionally may have information about where it resides in relation to sibling Panes (and their Frames). It optionally may have an outside border that "extends" the Frame. It may
optionally have an interior decoration which "clips" the view of the Pane. In this last case, the interior decoration may have scrollbars and/or a border.
The Frame also works as the view port into the Pane. As such, a Pane may be actually larger than its Frame, and the Frame then could provide the scrolling offsets into the view of the Pane.
Artists are that which do the drawing of what is in a Pane. Note: No longer does the "View" handle all of the drawing. All of the displayOn: methods simply get re-routed to the Artist for the Pane. This allows for the plugging in of different Artists into the same Pane. For instance, a TextPane could have a separate Artist for drawing word-wrapped and non-word-wrapped text. A "ComposedTextPane" could have a
separate artist for viewing the text composed, as well as maybe in XML format.
Agents are that which interact with the Artist and the Pane on behalf of the user. This sounds like a replacement of the Controller, but that's not the whole story.In the Pollock framework, the Controllers will have much less "View" related behavior. Instead, they will simply be the distributor of events to the Agent via the Pane. This means that our Controllers, while they'll still be there, will be much more stupid, and thus, able to be much less complex and less coupled to the Pane. Like the Artist, the Agent is pluggable. Thus, a TextPane may have a ReadOnly Agent,
which doesn't allow modifying the model.

Other pieces of the puzzle.
- All work to be done in the Pollock namespace.
- Most Panes will have Models, just like good old MVC days.
- The Change/Update mechanism will be taking a back seat to the TriggerEvent mechanism. The ValueModel will still remain, but Pollock will be adding a set of TriggerEvent based subclasses that will have #changed events. Internal to the Pollock GUI, there simply will not be a single place where components will communicate with each other via the change/update mechanism as they do today. While they will continue to talk to the Model in the usual way, there will be much less chatty change/update noise going on.
- The UIBuilder is broken into its constituent parts. That which builds, and that which maintains an inventory of references to Panes and other information in the window.
- The ApplicationModel is gone. It is replaced by the more appropriately named UserInterface.
- A new ScheduledWindow class (in the Pollock namespace) with two subclasses: ApplicationWindow and DialogWindow