Annotation Direction

Each Type has it's Own Class

See how KeypointInstance extends Instance for an example of this.

As we add more instance types, and as these interactions become more complex, we have realized that it is needed to have dedicated classes for each type.

Goals

• Isolation. Can edit class without effecting others, eg an update to Polygon doesn't effect Box

User Interaction Paradigm

As interactions become more complex, the built-in primitives of "mouse down" "mouse up" etc start to lose their meaning. Tracking state becomes confusing. For example, if a user is in the middle of auto bordering between two polygons, "mouse down" has a different meaning then say when drawing a new instance.

The goal overtime is to essentially create an "interaction" layer that tracks and maps low level things into our system level concepts about what a user is doing.

Further goals include:

• User centric command level. V1 of command pattern is centered mostly around instance events like instance creation and updates. We aim to extend this to higher level user concepts like "undo auto border".
• User centric readable code. The goal is to make working on the code more user friendly as the complexity continues to grow. Right now an engineer essentially needs to understand way to much in order to be effective. The goal is to be able to make these interactions as composable as we can.

User Interaction Concept Level Direction V1

 if (!current_user_interaction) {
        new current_user_interaction = UserInteraction(type = "user drawing")
        }
      else {
        current_user_interaction.process()
      }

User Interaction - Low Level Direction V1