This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Grid and Frame and Widgets
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
"I assume (vertical) scroll bars are a pretty easy next step?"
Vertical and horizontal scrollbars are already a part of the Grid and are a part of Pollock in general. It was actually a very early step to have the Grid support the standard Pollock scrollbars. Pollock has a general API for any pane that wants to use scrollbars. The standard Pollock scrollbars allow for the standard dynamic enabling and disabling if the scrollbar has nothing to scroll. Additionally, Pollock's scrollbars have the options to be visibly dynamic. This is that the horizontal and/or vertical scrollbar will disappear or appear depending on if there is anything to scroll or not.
"Is a "drop-down" in a column much more difficult? Would there be only one, or one per row?"
Actually, what you don't see clearly is that the third column is a DropDown list! The Display and Edit panes for each column are defined by column. Currently, the Grid supports InputFields, CheckBoxes and DropDown lists in any column. In the future, you will also be able to specify a TreeView in the first column. Also for the future the Grid will be able to support TextEdits (IOW, multi-line, justified editable text), and DisplayImages for any column. Finally, in the way distant future, I have plans to allow you to supply a Form in any column.
Let me describe for a moment what a Form in Pollock is. If you are familiar with Wrapper, it is the equivalent of a SubCanvas. If you are not familiar with Wrapper, then a Form is a host pane that in effect stands in for a Window as a subpane in a UserInterface. For instance, let's say you have a window user interface that defines an address entry interface. Things like Street Address, City, State, ZipCode, etc. You can reuse this definition by telling a Form to "host" it on another user interface. Thus, you could have a window, that has two of these address entry interfaces, each hosted by a Form, and you could thus have a "Billing Address" and "Shipping Address" on the same window, just by putting two Form instances on a window, and telling each to use the one the address entry interface.
So back to the Grid. This means that eventually each single cell in the column can be comprised of anything you can think of, as long as it can be defined as a UserInterface.
One of the goals of the Grid, but is slated for WAY in the future, is that it be able to emulate a specific window in Windows. That is the "Add or Remove Programs" window. In it, you can see, when nothing is selected, what seems to be a rather simple multi column Grid. The first column is a simple image, the second a bit of text, the third the word "size" and the forth a formatted number with KB, MB or whatever. However, if you CLICK on any item, the whole row changes into a multi line form. There are buttons and hypertext and all kind of things, that will look different depending on which item you choose.
Thus, the Grid will eventually have the ability to display each row differently based on if it is selected or not.
By The Way, I should point out that column headers, row and column lines are all optional in a Grid... Column lines on a Column by Column basis.
"Is a multi-column drop-down much more difficult?"
Technically, no. However, that is not about the Grid so much as it is about the DropDown... And that is not so much about the DropDown than a whole other design feature of Pollock.
Back when I was just beginning to work on the CheckBox, I was a bit distraught about the design I had for the widget at that time. I had already gotten this great pane/subpane thing going, and used it in the Button (so that a Button could host any number of other panes, images, labels, whatever), and was feeling that the RadioButton and CheckBox would be this kind of anomaly in the Pollock widget design. To me, if Pollock was going to really shine, then there shouldn't be hard coded exceptions to the general design ideas. To me, it would just sit there as a sore thumb, telling me in no uncertain terms that I had a crappy design.
One day, I was describing the issue to a colleague of mine, Rita Carroll, and between us we came up with this idea of an ActionDisplay widget. The ActionDisplay widget has one area, which is the Action part. For a CheckBox it is the box that you can click on. The Display part is an optional subpane that can be any widget. For the CheckBox, that would be the optional Label. It's pretty easy to see that this can apply to a RadioButton, just change the Action part to be a circle you can click on. Then, we came up with the notion of "Display Right" and "Display Left" option for the ActionDisplay. This allowed you to specify where, in relation to the Action part, the Display part will show. So, you could have RadioButtons and CheckBoxes with the labels to the left or right. This is a feature of Pollock's RadioButton and CheckBox, by the way.
Once we had the notion of the Display Right and Display Left, it occurred to us that there were two other widgets that could be ActionDisplays. Let's look at that: If we use a pair of stacked buttons, one with an up arrow and one with a down arrow, and an InputField (which could be read only or read/write)... AND we make it default Display Left.... Well, we have a Spin button! If we use a Button with a down arrow in it as the Action part, and an InputField (which can be read only or read/write) as the Display part... AND we make it be by default Display Left... We have all but the drop down part of a DropDown list!
For the DropDown list, all I had to do was supply some behavior for the Action part, when it was clicked. So, it opens what we call a Transient window "in the right place" and show a List in it! Hook it all together, and you have a fully functional DropDown list.
Now, there is this thing called a MenuButton. It really isn't used much in the Windows world, but it is common on Mac and X11. The MenuButton will actually just be a DropDown list, with a slightly different button image depending on the look, and instead of showing a Transient window with a List in it, it will have a Menu, which will do all of the right Submenu stuff.
Finally, back to your question. While I won't be supplying such an widget, you can easily create a "DropDownGrid" as a subclass of the DropDownList, just have it show a Grid instead of a List in the Transient. Do you want a DropDown Calendar? Same thing, just supply a Form with your calendar in it. The options are endless. We just won't be supplying all of them as part of the base Pollock widget set.
"How about radio-buttons?"
Frankly, unless you have more than one, I hardly see the point. For now, you can use a DropDown list to imply the same information as a set of radio buttons, but, because in the future you'll be able to define and supply a Form, I'll leave it up to the user to do that then.
"Does Pollock use a "layout" idea - row layout, column layout, anchor n,s,e,w? How about absolute positioning, layout with one element on top of another?"
Not for Grids. For a Grid, there is a collection of objects, and each column is a display of one attribute of that collection.
Pollock uses "Frames" as the layout mechanism of widgets. We have many different Frames to choose from. We have the OriginExtentFrame, which is absolute positioning and size. We have the FractionalFrame which allows you to specify that a widget be laid out with edges positioned a fractional offset from the edge of that pane's enclosing pane. We have the AlignmentFrame, which allows you to specify that the widget be laid out aligned top/middle/bottom and left/center/right of that pane's enclosing pane. We (will, not yet) have a RelationalFrame, which allows you to specify that the edges of a widget be laid out relative to the edge of any other widget (or itself).
I have thought a lot about doing Row, Column and Grid like layout things, and for now, have decided to not do them. I have looked at how SWT and HTML does them, and I believe that SWT does them as well as can be done, and have come away with the impression that even SWT's implementation is a horror.
That said... With knowing the current and future behavior of the Grid, you could have a Grid which shows no scrollbars, no border, no row and column lines and any number of widgets in each cell each hosted by a Form, and any cell be blank, and of course knowing that a Grid could be hosted in a cell's form...
Previous Topic
