Many changes have happened since the 7.3 and 7.3.1 releases of Pollock. With the release of 7.3, Pollock Feature Set 1 was complete. This blog covered behaviors and features that corresponded to what was in Feature Set 1 (FS1). Since then, and the lack of posting here that went with it, many changes have occurred. Some are obvious, some not.

Because I always post a public "In Progress" (but basically stable) version of Pollock after I speak at Smalltalk Solutions, and will be doing so in several weeks when the next stable point of Feature Set 2 is ready, it's time to talk about what's new, with some explanation.

Much of what's new affects the Calendar widget we worked on at the end of last year just before I stopped posting. That Calendar won't work, and won't even load cleanly in what is in FS2. So, when we're done talking about what's new, I'll be going back and re-doing our Calendar widget to make it deal with, well, what's new.

WinXP Look

Anyone who has used the release of Pollock in 7.3.1 will now see that it has the WinXP look. That's the second time I've done it, since I added that look to Wrapper several years ago, so it wasn't so much hard as tedious.

Additionally, Pollock used to have it's own MacOSX look policy, that partially diverged from the one in the base system. That look policy was merged into the one in the base, making Pollock and Wrapper properly co-exist.

TransientWindows

This is just one of many refactorings and changes that came about because of the need of the Tools. But first, some background.

Historically, TransientWindows came in two flavors, "Popup" and "PostedMenu." The reason for this is also historical. In the old days, going way back, it was resource intensive to create a class and slow to create a window. Therefore, the TransientWindow system was designed so that once a TransientWindow (drop down for a DropDownList, or Menu windows) was created, it was never thrown out, and instead was recycled. That recycling was just keeping the window, it's handle and it's instance around, and in effect hiding it. When a new transient was needed, it was taken from the holding pen, given the new contents and attributes, and then in effect un-hidden. For reasons that go beyond my knowledge, they made one for Popups and one for PostedMenus, each with it's own underlying OS "window class"... possibly thinking that both could be on the screen at once in some time in the future.

Be that as it may, TransientWindows no longer are a problem to instantiate, so long ago, Pollock got rid of the holding pen, and no longer recycles them. For the sake of no one, Pollock retains the creation messages to create both posted menu and popup and calls them.

Back to the TransientWindow itself. They are created in the VM, and have properties such that when you click outside them, they automatically close. Clicking in them is always up to the Smalltalk side of the code to deal with.

Now, if you want to have FlyBy help and that cool thing where a List box shows a fly over box with text for "long" items, when you click INSIDE it, you want the fly over to close, and that click to be passed to the underlying widget to do with as it may.

Well, the standard TransientWindows don't work that way. So, we made TransientWindow an abstract class, and added two new subclasses: ActiveTransient and InactiveTransient. Basically, ActiveTransient acts like the old TransientWindow, and InactiveTransient adds closing itself when being clicked and passing the event to the underlying launching widget.

The creation API has slightly changed.

ActiveTransient and InactiveTransient classes support:

 	newPopUpIn: <aRectangle> from: <aPane> 
 

Additionally, for those who care, and there is no reason that anyone should, ActiveTransient supports

	newPostedMenuIn: <aRectangle> from: <aPane> 
 

In all cases, "aPane" should be the pane (or window) which is launching the transient.

Calling this creates the transient, which you can then fill with components and set it's opening size and position, and then send #open. If you created an InactiveTransient, when it closes, no matter if you clicked in or outside of the transient, the click is passed on to the widget under where that click occurred.

Before we leave transient windows behind, there is one more bit of knowledge you may need if you ever have to create and manage your own transient windows. When a transient window is closed, by whatever means, it sends a message to the launching pane. Depending on the type of transient, it sends:

	clearInactiveTransient

 
or

 	clearActiveTransient

You don't have to respond to it, there are do nothing methods that take care if these if you don't care. It's there to allow you to do additional behavior if you need. In the guts of Pollock, it holds onto the instance of the transient when it is open, and when various panes get this message, they release the window as a bit of belt and suspenders cleanup. That kind of cleanup is something that is pervasive in Pollock, that some say I take too far.

Borders

There has always been an imbalance in the border API in Pollock, which is now cleaned up. Previously, all panes that took borders had the following API:

	border: <aSymbolOrNil> 
 

but if you sent the method #border, you got back the Border Decoration object itself. That was just, well, wrong. So it was changed to:

	borderType: <aSymbolOrNil> 

We then added (changed) the API:

	border: <aBorderDecorationOrNil> 
 

and now we achieve proper balance, a framework Feng Shui if you will.

BorderDecorations now get default artists. Prior to this, if you did a "BorderDecoration new", a decoration Artist was not installed in the Decoration. A decoration can't be used in a pane without an artist. This made for the developer to have to take extra steps to create and use an non standard decoration for special use. Now the platform default artist for decorations are automatically installed. If you want to use a different artist, you can still change it.

This gives the user the opportunity to munge up their own border decorations (or use unusual ones) and give them to a pane or window. One of the new tests adds the Motif button's "SevenWideFourToneBorderDecoration" to a Window as an example that it works... It's goofy looking, but it works.

As a part of all this, we moved the ScheduledWindowArtist as a subclass of ArtistWithBorder, to eliminate duplicate code.

Adios for now

Next time we'll talk about the big ActionDisplay change, where it and it's parts have been renamed, and also a hierarchy change that affects all Agents, as well as our old Action Display.