components status

I had hoped to have a usable version of the components framework by now. Instead, I have a reasonably self-consistent set of scaffolding that illustrates a lot of the concepts. It isn’t at a critical mass of functionality, and it has a lot of bugs and mis-steps. I was sure that copy semantics, multiple views, and event handling were going to be hard, as would getting enough corners tacked down so that I could start to cut the cloth. But they turned out to be much harder than I imagined. Nonetheless, I’ve now got a stake in the ground as the starting point. Maybe now there’s enough ‘it’ there that I can next report, “made ‘it’ do such-and-such”, or “added X to ‘it’.”

Below the fold is a diary/log of how I got to this point. (I originally called this a “bootstrapping” architecture, because components allow people to build their Croquet models from within Croquet itself.)

2/28 – start on bootstrapping architecture.
Code comment: what is the task and scope. Deep thought. Interesting.

3/1- Objects have behaviors and geometry. Both implemented themselves as behaviors. Behaviors are defined by programmers and are themselves objects with behaviors and geometry. Defined some behaviors.

3/2 – Got basic behavior working when hardwired from events: highlight when mouseover. Turned out to only be working because two bugs were canceling each other out. Spent all day tangled in Croquet low-level rendering and event-handlers. This is exactly what I want to shield everyone from.

3/8 – Copy semantics, Implemented lazy copying of behaviors so that copy doesn’t loop. Stuck on interaction model. Hard. Reread “Managerie” paper. Start of affordances model.

3/9 – Basic affordances: drag in plane, rotate in plane. Lots of trouble with coordinate systems. More stuff to shield people from.

3/10 – Drag and Drop. Took all day to get Croquet selection working while dragging (e.g., to highlight and discover what other objects the mouse is intersecting). Finally realized when I got home that it was the wrong task! We only want to highlight objects that collide with the object being moved, which might, for example, be restricted to movement in a plane. The pointerPick: selection that I got to work doesn’t so restrict. Lesson: 3D is different.

3/11 – half day on bootstrapping. Tree walk, collision detection, use in more meaningful drag & drop. Leaning towards behaviors having their own affordances that can be displayed by the component that the behavior is attached to. Clicking on the affordance triggers the behavior. Menus are the same conceptual topology, but the geometry is called ‘menu’ instead of ‘affordance.’ This is an example of explicitly named multiple geometric views. An alternative would be to turn this inside out: have the affordances be directly part of the component, and clicking on them triggers a behavior owned by the affordance, which needs to take its action on the original component. I think both styles can live together simultaneously, but I think it will be easier for users and developers if I stick with the former.

3/14 – half day on bootstrapping. Capture into existing group and release from group via drag & drop. Decision not to support laziness in language for now.

3/15 – release from group via drag & drop. Started text components. Decision not to support dependency tracking & update in language for now.

3/16 – TFlatText primitive. To make it editable, had to implement a shield around all the platform and version specific character event nonsense in squeak, tweak, and croquet. Components now get clean, reliable, uniformly high-level (e.g., unicodes) character events. (This version of Squeak doesn’t have Unicode, so I’m faking it with integers.) Decision not to support compiled-in (but late-binding, dynamic) component behaviors as Squeak methods for now.

3/17 – Bounds update properly (including parents) as we edit resizable text. Start of geometry to represent behaviors. Discussion of persistence, components as developer’s entrée, use in a developer’s workshop. Got first very primitive context menu working next morning.

3/21 2d layout for use in menus. Prismatic bounding boxes. Trouble with Croquet picking of nested components. Wonder what would be involved in a behavior that starts a recording for playback?

3/22 – Croquet picking of nested components. Introduced minimum sliceThickness to facilitate picking of planar stuff. Started organizing development into separable tasks and started tracking issues for them. Need frame separate from envelope for offset positioning. [ed. note: I didn’t actually go back to the separate frame and envelope idea until 4/26!]

3/23 – Primitive menu with a close behavior that can be invoked from within the menu. Start on affordances, but ran into circularities. Started to design and document a clean event handling model (but realized the next morning that it won’t help me with affordance circularities).

3/24 – Started to design and document geometry model.

3/25 – Components are lightweight and shared by the multiple views they have. This separates the behaviors in the view from the behaviors in the component. Views are TFrames and are what gets added to the display tree (but realized the next morning that it won’t help me with affordance circularities).

3/28 – huge code cleanup based on incorporating multiple views. highlight and behaviors (menu) are views. components_0.1.cs.

3/29 – get transfer of behavior from one component to another working cleanly after view reorganization. Start on persistence. Meetings.

3/30 – save (locally), restore (in context), delete.

4/1 – sick. document (but not yet implement) asymmetric views (no distinction between components and views).

4/6, 4/7 – Asymmetric views working and stable, but tried and failed to get Croquet to pick elements that are within other elements.

4/11 – Take snapshot changeset for Mark at U.Minn. Clean up code and class comments, example, and include an automated test suite. Test suite and example on clean Jasmine and on our NICT development image.
4/12 – I can’t remember!

4/13 – Got help. Jack is going to work one day a week on the mouse picking problem. Today I got character event stuff straightened out, such that if the mouse can get me any component object, I should be able to navigate by keyboard to the component I actually want. Now I can just work on everything else without being blocked by mouse picking. Fresh eyes might help the picking problem. Plus I now have a developer/user to support (even if only one day a week) which can only be a good thing.

4/14 – Very little time on components, but did manage to get keyboard navigation working (reliably!) in between meeting and family emergencies.

4/15 – half day on gesture reorg.

4/18 – Pointer events as normal gestures. Layout (e.g., position below or on right something else without changing other dimensions).

4/19 – Cleanup. Code to Mark.

4/21 – half day. Robust positioning.

4/22 – copy semantics. Aaargh!

4/25 – finished up copy. Hurray! Packaged up for David S, Andreas, Mark & Preston.