Isolate components and items from goocanvas as much as possible

[mbfraga]

Right now components and items and goocanvas are very interconnected in ways that make it hard to modularize them, build clean implementations on top of it, and eventually migrate from goo canvas.

I think we need to discuss how we may want to address this. To start, I want to propose having a few unbreakable rules to guide us in the right direction:

1. Components should not have any introspection into which item they are modifying, and they should not have to worry about synchronization between components-items-canvas (this should be built on top on another indirection layer).
2. Items should be able to exist without a canvas associated with them. This would allow items to be prepared and modified in-place, and then afterwards added to the canvas. This would help build an easy-to-use item insertion api.

A first step here would be to extirpate the synchronization of components and items out of the component code itself. One step in the right direction would be to add a "dirty" state to components. Items would then have a "update_components" command that would check for any dirty components and run the necessary code to synchronize the component to the item. The synchronization code itself should be static (for now it could live in each component) function / method that updates the item and marks the component as not dirty.

The second step would be to have items not require a canvas or artboard when being constructed. This would allow better prepping of items before being inserted to the canvas. It would also allow for better deep-copying and other operations.

These are some initial thoughts, but I think it'd be nice to start moving in this direction as soon as possible.

[ghost]

What a great Idea

[mbfraga]

I thought about it some more, and here are some thoughts on where we could go with this.

Make a class that is an Instance. An Instance holds a Value (model) and a reference to the corresponding ViewItem (view). The Value is what currently is called the CanvasItem, but it would not subclass from Goo.CanvasItem.

The hierarchy is as follows:

• Instance (with a uid)
  • Value
    • Components
  • ViewItem

Whenever a change is made to the value of an item, there needs to be a synchronization step to update the view. But multiple changes can happen before a synchronization happens. The source of truth here is always the Value.

Eventually we could have values actually have value semantics or similar. This would provide certain nice guarantees.

[mbfraga]

Another benefit here is being able to define coordinates however we want--and not the way that goocanvas forces us to.

So if we want coordiantes and rotations to always be defined in global coordinates, we could do it trivially.