This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Where Are We Now - Part 1
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
"It would be nice to have an update of where is Pollock now. What's working, and what's coming soon."
Ok, here you go.
Currently Pollock is officially at "Beta 3." Beta 3 shipped in the Preview directory of VisualWorks 7.2. Here's what is in Beta 3:
Windows
DialogWindow
ApplicationWindow
TransientWindow
Widgets
Button
DisplayLabel
DisplayImage
CheckBox
RadioButton
Popup Menus
MenuBars
InputField
TextEdit
ListBox
Grid (Generalized Dataset & Table)
TreeView
DropDownList
Form (Generalized Subpane/Subcanvas)
TabControl
Toolbars (With Button, InputField and DropDownList Widgets, the latter two with optional Labels)
Frames (Layouts)
OriginExtentFrame
AlignmentFrame
FractionalFrame
Behaviors
Trigger Event System
Dynamic Scrollbars
Dynamic Look & Feel Changing
Unlimited Undo/Redo
Fully Configurable HotKey System
Multi Process Compliant
Models
UserInterface (replaces ApplicationModel)
WidgetInventory
ValueEvent (replaces ValueHolder)
ObservedList (replaces List)
Tree & TreeNode (replaces TreeModel & TreeNodeWrapper)
Column & Row (for Grid)
Looks and Feels: All widgets above from Button through ListBox are fully implemented in the Windows 9x/ME/2K Look & Feel, the MacOSX Look & Feel, and the Motif Look & Feel. The rest of the widgets currently only have the Windows 9x/ME/2K Look & Feel. By the time Pollock hits Production 1 (which I'm working on now) ALL widgets will have ALL Looks & Feels. A Windows XP Look & Feel is scheduled for Production 2
Let's get into some of the details of these. Widgets that I don't talk about below work as you expect... they aren't mentioned because there's nothing special about them... except that they work
Button
The Button can have both a label and a image... or both. In fact, the Button represents one of the major features of Pollock. It is a Composite Pane. A Composite Pane can have any number of subpanes in it. In effect, a Window is a kind of Composite Pane. The upshot of this is that a Button can have any pane displayed in it and any number of panes... 10 labels, 5 images... 4 CheckBoxes... you get the idea
DisplayLabel
A Pollock DisplayLabel can be either a single line of text, or it can be multiple-lines of text. If it is multiple-lines, the text is automatically word wrapped for you, and can be displayed justified either center, left or right.
DisplayImage
The Pollock DisplayImage combines many image features into one. Besides having an image and a mask for that image (to display the background through the image), it also supports an optional disabled image and disabled mask. Not only does this allow you to enable and disable an image, the actual images displayed can be different for the disabled and enabled views. A DisplayImage may be used as a window icon. No longer do you have to play with a separate Icon class, nor worry about having all the image bits just so.
CheckBox & RadioButton
Both of these widgets can be displayed with or without a label. Also, they both can be set to display their label to the left or the right of the check or radio.
InputField & TextEdit
Besides the unlimited Undo/Redo, there are two very important improvements in the Pollock version of these widgets. Just like the current editing fields, you can have formatted text, with color and emphasis. What's new here is that when you select text that is colored, the "foreground" color of the text being selected no longer continues to display in color. In other words, selected text is properly white on "selection background color." This selected behavior applies to things that are selected in a Grid, Tree and ListBox also. You can finally actually read text that is otherwise colored when it is selected. The other improvement is where Pollock finally separates the notion of Cut and Delete. In Wrapper when you delete text, it is automatically added to the paste buffer. Now, while both cut and delete are undoable, only cuts are added to the paste buffer. Oh, and talking about Undo/Redo. Wrapper had this ugly habit of undoing a cut wherever the cursor currently is, instead of where the cut happened. Now, Undos and Redos always happen where the occurred
ListBox
The ListBox (as well as the Grid and TreeView, which are collectively known as Enumeration Panes) now do selection the way that all OS's do. Wrapper had this behavior I have come to call "Toggle Select." If you select an item, and then "click" on it again, it becomes unselected. As the name suggests, it toggles the selection. In Pollock, the standard behavior is no longer "Toggle Select" but the selection behavior we have all become accustomed to over the years in the various OSs we use. In Pollock you can turn on "Toggle Select" as a backwards compatible behavior, but by default, it is off. Also new to Pollock is the ability to dynamically change any of these Enumeration Panes from single select to multiple-select. The Pollock ListBox allows you to also have optional icons for each item, as well as the ability to specify color and emphasis on an item by item basis (or overall). The ListBox allows you two selection display modes. You can have either standard highlight selection, or check mark selection... and you can change that dynamically
Grid
The Grid is a whole new widget, combining the capabilities of the Wrapper framework's Table and Dataset. Like the Wrapper counterparts, the Grid can display and edit InputField, CheckBox and DropDownList cells. Instead of having to deal with very convoluted column construction, there is a new Column object. In it, you can define how the column gets its value the current row's item. You can specify the accessor method (or block) to the value, as well as a mutator for when you are editing. Also, you can specify a path to the value. Thus, if you had a list of Employees, and you wanted one column to be just the zip code, but the Employee has an Address object that held the zip code, you could specify the access path as #(#address) and then the accessor as #zipCode. The access path is a collection of accessors and/or blocks that perform against the main item, in order. When it gets to the last item, then the accessor is performed (or in the case of editing, the mutator is performed). A Grid supports the ability to do column sorting, by clicking on the column header. You can specify the sort accessor as a separate accessor or block for sorting. You can turn off column sorting overall, or by the column. Column headers and row headers are optional. Column headers can look like labels or buttons, which are more like what we see in platform Grid like widgets. You can center, left or right justify column headers as well as the cells in the Grid.
Some other features of the Grid are the ability to turn on and off row lines. The ability to turn on or off column lines overall, or on a column by column basis. Of course, you can resize columns... more importantly, you can resize columns from the BODY of the grid, not just in the area of the column header, if column lines are turned on. You can also resize individual rows. Yes, each row in a Grid can be a different size! You can have single and multiple selection dynamically as with all Enumeration Panes. You can also dynamically turn on or off Cell selection. Similar to the ListBox, you can specify color and emphasis overall, by the row, column or cell
Bottom line, the Grid is one amazing little widget, and is in effect the ListBox's smarter brother. But don't think we're stopping there... The Grid has more features to come, both in Production 1 and after that.
TreeView
Gee wiz. After all that build up with the Grid, the TreeView seems like such a let down. The TreeView allows you to do all the single and multiple select stuff dynamically. It lets you specify all that good color and emphasis stuff like the Grid and ListBox. It let's you turn on or off tree lines dynamically, as well as the "plus/minus" open/close images. You can specify the icon for opened, closed and leaf nodes, or you can specify a different icon for each item. You can show some or all or none of these icons as you wish. Unlike in Wrapper, a TreeNode object knows it's parent, so that's now easier to traverse from parent to child and back.
Window, UserInterface & WidgetInventory
First, Pollock has separate Dialog and Application window classes. This allows a separation of behavior. In Wrapper, an application user interface is has a "model" that is the ApplicationModel subclass. In Pollock, Application and Dialog windows have a UserInteface instance instead. Like in Wrapper, a UserInterface can define a specification for a window. In Pollock, both Dialog and Application windows can be used to realize a specification. In Wrapper, it is almost impossible to create an window with widgets by hand, with code. A major reason for this is because of the very tight coupling between the Builder, the Wrappers themselves and the Widgets. In Pollock, a Builder is not required to create a window at all. In fact, a specification isn't required either. You can just code away if you want. In Wrapper, the Builder stuck around after it did it's job and held onto an "inventory" of the widgets it built. In Pollock, the UserInterface has a WidgetInventory. Whenever you add a pane to a window, it automatically adds that widget to the UserInterface's widget inventory. The WidgetInventory has a simple #paneAt: API, that gives you quick and easy access to any widget. If you use specifications in Pollock (and they can be either in XML or the standard LiteralArray format), then you ask the Pollock builder to build the window, and when the builder is done, it goes away, leaving behind your UserInterface with its WidgetInventory, ready for you to do what you need. If you are using a specification and the builder, the UserInterface is notified when each window, toolbar, menu bar or pane is created. With this notice mechanism, based on the Trigger Event system, you can get each widget after it is built, allowing you to tickle then with code as the window is being built.
Form
This widget is the basis for fantastic things in the future (and even in the present). A Form is basically a fancy kind of Component Pane, like our Button. Yes, this means that each Form can have any number of subpanes (and sub forms) within it. It has Scrollbars, so that it can be used as a viewport into a set of widgets within it. The Form also has the ability to take a UserInterface specification, and build itself from that specification, hosting the widgets. What may not be apparent from this is that there is an amount of protocol similarity between a Window/UserInterface and a Form. A Form has it's own WidgetInventory. When a widget is added to a Form, it adds that widget to it's own inventory. But wait, says you, how do I get to a widget in a Form, or a sub Form, or a sub sub Form, from my UserInterface? Well, remember the #paneAt: API I discussed above? It not only takes a single widget ID to look up a widget, it also can take a collection of widget IDs. A path if you will. So, let's say we have a Customer UserInterface. In the Customer UserInterface, it could have a Form for Addresses. That Form may have two Sub Forms, one each with an instance of an Address specification... One for Bill To one for Ship To. From your UserInterface, you can reach the Bill To street widget by sending #(#Addresses #BillTo #Street) as the parameter to #paneAt:. Like a Window, you can either build a Form from a specification, or by hand with code.
TabControl
This is where we show that the Form is a great thing. In Wrapper, the TabControl is in effect a "list" object which simply shows the tab buttons, and there is one "Subcanvas" which the user must build/install manually whenever a new Tab is pressed. In Pollock, a TabControl is a bunch easier. First I should point out that I probably should have called it a PageControl. Why? Because in Pollock, the "Tabs" themselves are optional (but by default are on). This design is modeled after the way that the Windows(tm) TabControl is designed. The effect of this is that a TabControl without Tabs is the basis for a Wizard. Just a bunch of pages, that are programmatically navigatable to. Where Wrapper had one Subcanvas where you had to build/install (and rebuild/reinstall) each view whenever the Tab is pressed, the Pollock TabControl is made up of a series of Pages. Each Page has a Form. All Pages are alive when you build the TabControl. You can add and remove Pages. The Page is basically a holder of information. It holds a Form of course. It also holds an optional label and an optional image that can be displayed on the Tab. If you specify both a label and an image, you can say which is displayed "on the left" in the tab. You don't ever have to create these Page objects. There is an API in the TabControl for adding pages, where you specify the Form, label and/or image, and the TabControl takes care of the rest. You can get the active page number, and access any page via a #pageAt: API.
Menus & Toolbars
Pollock has MenuBars, Toolbars and Popup Menus. Improvements in MenuBar includes the proper recognition of the F10 and naked ALT keys to make a MenuBar active. All menus, not just MenuBar menus can have items with icons, check selection, accelerator keys and hot key text. Toolbars, which in Beta 3 only have the Windows Look and Feel (where MenuBars and Popup Menus also have MacOSX and Motif Look and Feels), have the standard Toobar Buttons. They also can have Input Fields and DropDownList widgets. Either of these Toolbar items can be specified to have an optional label to the left of the widget. Toolbars do not detach, nor are they scrollable or "re-dockable". These features are on the task list for a release sometime after Production 1.
Frames
In Pollock, each Pane has a Frame. The Frame describes the size and position of the Pane within it's enclosing pane. Whenever a pane is added to a Window or a Form (or sub Form ie. "page" in a TabControl) widgets are situated relative to their enclosing pane. Thus, if you give a Button a frame with an origin of 10 @ 10, and add it to a window, that button will be 10 @ 10 in the visible area of that window. This means that if there is a MenuBar, that takes up say the top 20 pixels of the window, then the Button will place itself at 10 @ 30. If you have Form that itself is at 10 @ 10, and then put a Button in it that is at 10 @ 10, and there is a MenuBar, then, the Button will show at 20 @ 40. That is, the Form will be at 10 @ 30, and the Button will be 10 @ 10 relative to that Form.
The simplest kind of Frame is an OriginExtentFrame. This allows you to specify an origin for the pane and it's extent. Next is an AlignmentFrame. An AlighmentFrame allows you to specify the vertical and horizontal alignment that the pane will sit itself within it's enclosing pane. You can specify horizontal as #centered, #left and #right and you can specify vertical as #centered, #top and #bottom. An AlignmentFrame is really meant to be used mostly for DisplayLabels and DisplayImages. The last Frame for Beta 3 is the FractionalFrame. With this, you can specify the fractional position for the top, right, bottom and left edges relative to the enclosing pane as always. You can also specify an offset, plus or minus, from that position. This is the Frame you use when you want a widget to grow/shrink or track against an edge of the window when the window is resized.
Scrollbars
We'll finish this post with a quick overview of Scrollbars. Scrollbars are available for all Enumeration Panes (Grid, ListBox and TreeView), the Form as well as the TextEdit. New to Pollock is the ability to tell a Scrollbar to be dynamic. That is, instead of just being disabled if there is nothing to scroll in the direction for that scrollbar (horizontal or vertical), they can appear and disappear as needed.
That's pretty much where Pollock is today in Beta 3. Next post, I'll talk about what's next (Production 1), and where it stands as of this week. Then I'll finish up this series of posts with a hint at what is in the future for Pollock for widgets in Production 2 and Production 3.
Previous Topic
