This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Pollock Changes - Part 4 Feed Title: Pollock Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml Feed Description: Pollock - the next VW GUI Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Pollock

Today I review some more of the small but important API additions and refactorings

Forms

Forms now have a new method where you can specify an explicit display extent:

	contentsExtent: <aPointOrNil>

If you specify this value for a Form, this is the "virtual" size you want the form to have. This helps with a Form that is fully made of panes with fractional frames. For instance, let's say you have a Form that you laid out optimally to be 200 @ 200. Now if you host it in a window in an area of 100 @ 100, with scrollbars so that the user can see the rest. By giving the form a contentsExtent of 200 @ 200, then the panes will lay themselves out to be 200 @ 200, and the scrollbars will work as you would expect.

Up until now, the Form was trying to guess what was the optimal extent, and it failed, horribly.

We also added two new values:

	verticalScrollSteps: <anIntegerOrNil>
	horizontalScrollSteps: <anIntegerOrNil>

This allows you to specify, for a Form, how many vertical or horizontal steps a Form's scrollbars should take when pressing the up/down buttons from the maximum to the minimum positions. If you specify nothing, the default is 5.

DropDownList

Reg Krock pointed out that while there was a way to set the displaySelector for a List, but not for a the list part of the DropDownList. That was wrong. So I added:

	listDisplaySelector: <aSymbolOrNil>

to the DropDownList, that does the right thing. As before, if not specified, the default is still #displayString. The problem was, as Reg pointed out, if your model object was a "Domain" object thing of which you were only accessing a part of, you couldn't get to it the way it was.

Thanks Reg!

Properties

Because of many disparate requests, we have added a "properties" instance variable to the AbstractAgent. However, you can't get your hands on it! It is an "Implementation Thing", and hidden. But there is a global API that is available to ALL parts of the Pollock framework: Pane, Agent, Artist & Frame:

	propertyAt: <aKeyObject>
	propertyAt: <aKeyObject> put: <anObject>
	propertyAt: <aKeyObject> ifAbsent: <anBlock>
	propertyAt: <aKeyObject> ifAbsentPut: <anObject>
	propertiesKeyFor: <anObject>
	propertiesIncludesKey: <aKeyObject>
	removeProperty: <aKeyObject>

The UserInterface has it's own "Properties" stuff which is stored in it's widget inventory. This is for panes. This way you can attach a property to an individual pane. Properties are properly transferred if/when you change the look and feel. By default though, if you use the #setAgent: method for a pane, it does not copy the current agent's properties to the new agent. So, we added a new method:

	aPane swapAgent: <anAgent>

If you use this, and you've been playing with plugging agents around, then you can be sure that the properties will be copied to the new agent.

More TransientWindow stuff

The TransientWindow had this ugly API where it called back to the launching pane when it was closing with a method named #clearDropDown. It was called both on local popup menus and drop down widgets. It is important in that it made sure to forward events (such as the nameKey of a menu item chosen) or values (the selection in a drop down list) to the underlying launching pane.

We have renamed this to #clearActiveTransient, and moved this call to ONLY the ActiveTransient window. To mirror this, we added a method #clearInactiveTransient call to InactiveTransients, which by default do nothing for now. It's there if you need it for InactiveTransients (fly by windows).

Vassili Asks, We Accommodate

As some of you know, Vassili Bykov is our Tools chairperson, so to speak. He is also currently my #1 customer. He is working on our tools, and Splash, the interactive UI building tool for Pollock. So, he uses Pollock pretty much every day. As he works, he uncovers various holes in our API and bugs and so on. These issues he comes up with we discuss heartily. These are some of the results of these issues.

Measuring Text

We refactored the text measurement API so that it is available for all artists. Now, from anywhere you can send:

	measureTextExtent: <aStringOrTextOrNil>

It answers a point. It can handle any text. If the text has CRs, it breaks them into lines, and gives you the width of the longest line, and the height of the text in lines * lineGrid. It properly answers 0 @ lineGrid for an empty string or text, and 0 @ 0 if you passed it a nil.

For every Pane or Model class that triggers events, I have added a "Events Triggered" section to the class's documentation.

Local to Global Coordinate Translation

Vassili needed a uniform coordinate translation protocol, so he wrote it, and wrote tests for it, and I included it:

	translate: <aGeometric> from: <aPaneOrWindow>

Here's is comment, which is better than anything I could write:

"Translate aGeometric from the coordinate system of aPaneOrWindow to that of the receiver. This is a highly polymorphic message, and the arguments can go beyond what is suggested by their names. aGeometric can be anything that understands #translatedBy:. Points, Rectangles and Events are the most common examples. aPaneOrWindow can also be the current Screen. The answered geometric is a copy of the argument (as long as #translatedBy: is correctly implemented by aGeometric)."

Eyes Wide Open

Well, the Post Smalltalk Solutions Interim publish is almost done. Watch for the announcement here in a few days.