Today we look at some of the changes in the guts of the system.
Scrollbars
Previously, the Scrolbars were using OriginExtent frame. With an OriginExtent frame, it made it such that on every resize or other size/position change to a pane which had scrollbar, the frame for the scrollbar itself had to be recalculated and reset. This involved a lot of Wrapper style downcast kind of code. Uglier than sin. By changing to the FractionalFrame, the scrollbars laid themselves out without the need for this notification code. Additionally, code that had to go around and test if both scrollbars were visible, and then re-adjust for the "dead corner" turned out to be no longer needed. This is because the frames, now based on the bottom/right edge of the displayable area of the host pane, automatically put them in the correct "out of the dead corner" position.
This was a bit of a surprise for me. When, after doing the basic changes for the new FractionalFrame work, I went back to do the "dead corner" work, and found that the fractional frame had taken care of it for me. So, off I went to remove even MORE code that wasn't needed! I should have known this when I started this task, since when I saw it, I immediately understood what was happening. <sigh>
Because of this, a refactoring that I was going to do, which was to better handle dynamic scrollbars when all scrollbars are on and the dead corner was flickering was obsoleted by the fractional frame change. So, scrollbar refactoring task #2 was fixed by #1.
Next, there was a bunch of ugliness in the scrollbar decoration. When a scrollbar decoration had to have it's thumbs sizes or positions updated, it would do a separate invalidation for each scrollbar. If it was a grid that had column headers (which are a part of the Grid's decoration), it did a third invalidation for the headers. I've hated this for a long time. So this refactoring was to add a new kind of invalidation request: invalidate interior decoration. Only panes which have scrollbar decorations use it (TextEdit, Form, and all Enumeration panes). This adds a new "displayOn:" method, called displayInteriorDecorationOn:. This then only calls the displayOn: for the decoration, which does all two (or three) parts in one display call.
While I was at it, I fixed an ugliness in the Grid's decoration, where it was doing the scrollbars in one invalidation pass, and then the headers (if there were any) in a second. This caused the headers to visibly redraw after the scrollbars. Now they redraw in the same draw cycle, and in fact, the whole thing seem slightly faster.
As a whole, this bit of refactoring caused some more code to become unused, and become simpler... one of the main points to refactoring, of course.
In the course of these scrollbar refactorings, I found a dead up bug in the dynamics of adding a border to a pane that had scrollbars. If you had a pane, which had scrollbars and a border, then dynamically removed the border, suddenly the scrollbars wouldn't show anymore. Stupid code was the cause here. The re-calculating of the displayable bounds of the decoration simply forgot there might be scrollbars. Putting in the appropriate code fixed this bug.
Damage
We now capture the "withBackground" flag if an invalidation comes through with that turned on during a invalidationSuppressWhile:.
Previously, and still in Wrapper, if you suppress invalidation and do a lot of stuff that causes damage, and one of those things was a damage that wanted the background to be redrawn, it wouldn't. That of course could cause all kinds of ugly. Now repainting the background doesn't get lost.
Notes From The Design Sessions
Well, as I said before, last week Vassili Bykov and I had one of our now regular deep side by side pair sessions with Pollock and Splash, and all things in between. As suggested last time, ComponentPair is going away. We have come up with a new design that covers all the old ComponentPair panes. We call it AssemblyPane.
We agreed that the ComponentPair design was missing on several cylinders (my one and only automotive metaphor). These panes (CheckBox, RadioButton, DropDownList, MenuButton and SpinButton) may have real or fake subparts, but they act like whole standalone panes. In other words, they are an assembly of panes, with the outer crust looking like a single pane, but the warm and juicy filling hiding the details (now I'm onto a baker metaphor... someone stop me!).
So, sometime around the first of the year, after Feature Set 2 is complete, the new AssemblyPane refactoring will be done as an early task in the final Feature Set: #3. Details on that, then.
Within An Inch Of My Life
Back in early July, at Smalltalk Solutions, my resolve to keep the "Trigger Event" system based on Symbols, was beaten to a pulp. For years now, I have been asked and prodded and cajoled to make the system instance based. For reasons that no longer matter, I held fast. But, lying in the bloody pulp as I was on the floor of the lunch/vendor hall, I finally groaned "Uncle" from somewhere behind the mouth full of broken teeth.
After being picked up and unceremoniously plopped in a chair, I made one demand: Vassili had to produce the design and reference implementation. While rubbing his now sore fists and wiping off the baseball bat, he agreed.
During our sessions last week, we came up with a name for this replacement framework: Announcements. He has already done the reference implementation, and gotten permission to release it into our base system... hopefully for 7.4. We will be reviewing it, and doing any clean up needed over the next several weeks. It fits neatly along side the Trigger Event framework, and indeed re-uses some of the APIs.
Early in the Feature Set 3 cycle, I'll be moving Pollock to use this new framework.
Vassili has promised to go into more detail on his Blog soon. Hopefully by the time my bandages come off.
New Pane
As part of the AssemblyPane work, we came up with a new pane that would get rid of the fake stuff in the guts. We call it the ActiveImage. It is sort of a super DisplayImage, that can have up to 5 different views. First, there is the primary image. This is just like the main image of a DisplayImage. Also like a DisplayImage, there is a disabled image. The three optional images are: transition, secondary and fly-over.
Unlike the DisplayImage which is pretty much inactive when it comes to mouse events, if you supply a fly-over image, it automatically will switch to that image when the mouse flys over the ActiveImage.
The transition image, if supplied, is shown when you press the mouse on an ActiveImage. This image stays showing until you release the mouse, no matter where you move the mouse. If you release the mouse button within the visual bounds of the ActiveImage, and you have supplied a secondary image, the image then shows that image. With a secondary image, the ActiveImage acts like a toggle, back and forth.
This ActiveImage supplies all the needed behavior of the previously faked check and circle of the CheckBox and RadioButtons, respectively. It also supplies needed behavior for other kinds of widgets, such as the disclosure triangle of a TreeView in the MacOSX look, and more.
I hope to have this new pane complete for 7.4. Then I'll use it extensively in the coming AssemblyPane early next year.
Just A Little Bruised
The core of the ObservedModel framework of Pollock is, well, not really Pollock specific. I have been asked several times to release it separately so that it can be used by those who want to move off of the update/change framework sooner.
This time, before even getting knocked unconscious, I have agreed to do it. But first, I want to re-do it using the new Announcement framework. Keep an eye out here for when that is ready... maybe not until late fall.
Licking My Wounds
That's all for now. Next time we'll talk about the changes to the Form, the new properties capability and some more API additions and refactorings.
By then I hope to have completed the current interim work, and published it to the Public Repository for all to see and use.
Previous Topic
