This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: How To Build A GUI With Pollock - The Window 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

One of the first things someone usually wants when they approach a new framework, is to get quick results. Pollock is all about quick results! In this session, we'll show what it takes to create a new UserInterface, and open it's window.

As we move along, I'll be first showing code that does something, and then I'll describe details about what that code is all about.

So, let's get down to it. When you are going to write a UI with Pollock, you start with one decision. Are you going to create a standard window or a dialog window. That decision determines what class you want your user interface to subclass from. In Pollock you choose UserInteface for standard windows, and DialogUserInterface for dialog windows. Our class hierarchy browser will use a standard window, so we'll subclass from UserInterface. Here's what that looks like to create that in a VisualWorks browser:

Smalltalk defineClass: #ClassHierarchyBrowser
	superclass: #{Pollock.UserInterface}
	indexedType: #none
	private: false
	instanceVariableNames: ''
	classInstanceVariableNames: ''
	imports: ''
	category: 'PollockBlog'

For those following along who don't want to actually type in things... I have published this as a Package named "PollockBlog" on the Cincom public repository. The above is Version 1.0.

Now, let's go over to a workspace, and type in the following:

	ClassHierarchyBrowser open

Select that text and "do it"

Bam! A window has opened in the center of the screen. We're barely 5 minutes in (if you're not a slow reader like me, maybe less), and we already have a window for our application! You'll notice it is a fully functional window. It opened in the center of your screen (probably... more on that below). You can resize it. You can minimize it, you can maximize it, and it has the Pollock window icon. However, it's pretty small by default: 200 @ 200 and it has no title.

Our next step is to make it larger, since a class hierarchy browser should be somewhat bigger, and let's give it a title.

To do that, we now need to learn a bit about the Pollock UserInterface framework. As you saw, when you send open to your UserInterface subclass, a window opened. What the UserInterace did for you was create a window, and then open it. What you didn't see is that the UserInterface framework has called "Do Nothing" methods in UserInterface, that allowed you to manipulate the window, add menus and toolbars, add components and hook them all together.

The Pollock UserInterface calls the following methods in your subclass (or in the UserInterface if you don't write your own) in the following order:

Some of the things mentioned above, such as Menu and ToolInventory will be explained in later sessions when we do the MenuBar and Toolbars and so on.

As stated above, we want to make our window larger and add a title. To do this, we write our own hookupWindow method.

	hookupWindow
		self mainWindow frame specifiedSize: 500 @ 400.
		self mainWindow label: 'Class Hierarchy Browser'

The above is published as version 1.1 in the Package named "PollockBlog" on the Cincom public repository.

So, let's go back to our Workspace and execute the same code we did last time. Now our window is larger, and has a title.

First, we should talk about #mainWindow. The UserInterface has a method called #mainWindow that answers, well, the main window for your application. But there is more going on in there. If you look at the implementation of UserInterface, there is no window instance variable. You will see an instance variable named widgetInventory (among others).

Instead of having to have an instance variable for every possible pane you want to use in your application, the UserInterface, when it is created, creates an instance of WidgetInventory. In here is where all the widgets in your application get placed. The first thing the UserInterface does, when it creates your window, is to put it into the widget inventory. You can access any item in the widget inventory by sending the #paneAt: method, and passing in the "ID" of the widget, a Symbol.

In the case of the main window, it is automatically added with the id #mainWindow. The UserInterface has a convenience method named #mainWindow, so you don't have to write:

	self paneAt: #mainWindow.

However, if you chose to, you could access the window like that.

We sent the message #frame to our window. If you have been following along in the earlier blog entries, you'll know that every pane has a frame. The frame determines the origin and extent of your pane. There are several different frame types: Relational, Alignment, OriginExtent and Fractional are the standard ones for a standard Pollock pane. The window though has it's own special frame: WindowFrame.

A WindowFrame has information that regular panes don't have any use for, but windows do. That includes the opening size, the opening position, the maximum size and minimum size. All of these have defaults. For instance, the opening size defaults to 200 @ 200. The maximum size is the size of the current screen. The minimum size 20 @ 20. This is why, in version 1.0, our window opened with a size of 200 @ 200, and could "Get Small" as well as full screen.

In the #hookupWindow method, our window hasn't opened yet. In fact, the window isn't opened until after the final #hookupInterface method is finished executing.

The #label: method simply take a string and tells the window to use that as it's title.

Way up there, I said that your window "probably" opened in the center of the screen. It may not have. If your user settings have been set for Window Placement to be "By User", then the system will go into User Placement mode for your window. Describing User Placement is out of the scope of this posting, but it is described in the documentation. The point is, if you had that turned on, it wouldn't have been opened in the center of the screen.

Pollock (and indeed, this behavior has existed in Wrapper for a couple of years) has a bunch of other opening options. For instance, you can have your window opened at a specified position, centered on the mouse, cascaded or at the last saved size and/or saved position.

Before we finish for today, we'll talk about how to use these in Pollock. Before, we talked about other instance variables in UserInterface. One you may have noticed is "openingInformation." You never have to talk directly to that instance variable... instead, there are convenience methods in UserInterface to get and set the appropriate values for this, that are then used to determine where, what size and how to open your window. These are:

• #openType:
• #positionType:
• #sizeType:

By default, if you don't change any of these, you get the "System Default" opening type, which is currently either "User Placement" or "Screen Center" and in the future, Pollock will add "Cascade." This is indicated by having an openType of #systemDefault. The valid values for openType are:

• #systemDefault
• #userPlacement
• #cascade
• #screenCenter
• #advanced

The middle three simply override whatever is the System Default. The last one says "I want to use one of the advanced window opening capabilities." These advanced opening capabilities are controlled by the #positionType and #sizeType values.

The valid values for positionType are:

• #systemDefault
• #screenCenter
• #mouseCenter
• #mouseCenter
• #userPlacement
• #lastPosition
• #lastPositionAutoSave
• #specifiedPosition

You see, some of these are just the same as in the "higher levels." One new one is mouseCenter, which opens the window centered on wherever the mouse is on your screen. This is typically used for Dialog windows.

Two other new ones are #lastPosition and #lastPositionAutoSave. Anytime you want when a window is open, you have the option to save it's position (and size). You can do this by calling the UserInterface #saveLastPosition and/or #saveLastSize method(s). This automatically saves the size and position values to a class instance variable. If you have saved the last position, and specify the positionType as #lastPosition or #lastPositionAutoSave, the next time the window opens, it will open in the same place that was saved. If you specified #lastPositionAutoSave, not only will it open in the last place it was, but when you close the window, it will automatically save the position the window was in at the time it closed.

If you set the positionType to #specifiedPosition, then when the window is opened, it looks to the window's frame to get the openingPosition value, which by default if you haven't set it, is 40 @ 40. You may be wondering "Where does a window open the first time it is opened with positionType #lastPosition or #lastPositionAutoSave, and that window has never had it's position saved before?" Well, in that "No Saved Value" case, it looks at the openPosition value of the frame, just like #specifiedPosition does.

Valid values for #sizeType are:

• #lastSize
• #lastSizeAutoSave
• nil

These are simple. The #lastSize and #lastSizeAutoSave act exactly like the positionType's #lastPosition and #lastPositionAutoSave, except they apply to the size of the window instead of the position.

If you don't specify anything, which is the default, then when the window is opening, it gets it's size from the window frame's specifiedSize, which by default as we noted above, is 200 @ 200.

Here are how you might use some of these in your #hookupWindow method:

	self openType: #cascade

	self openType: #advanced.
	self positionType: #mouseCenter

	self openType: #advanced.
	self positionType: #specifiedPosition
	self mainWindow frame openingPosition: 350 @ 200.

Well, that's enough for today. Next we'll actually add panes to our window.