Restructure the way that references and adjustments are called.

[trystyncote]

As of right now, the structure for various objects is... scattered.

For clarity, I'm not going to restructure some objects that aren't as scattered, if at all. Those being:

• The qualms module;
• The _utils module;
• The _video_crafting module; and
• All files in the base package directory (_separating_instructions, errors, metadata).

_motion_tree

• [x] completion

Firstly, I'd like to contain the dump(), parse(), and walk() into a module object, instead of having it externally accessible (this is kind of confusing). So instead, it'd be motion_tree.dump(), motion_tree.parse(), and motion_tree.walk().

Secondly, I think that the nodes module could be unpacked, so that instead of, for instance, _motion_tree.nodes.Continue, it'd be motion_tree.Continue. This is mainly because the motion_tree module is adjacent in behaviour to an abstract syntax tree, but instead focused on the ordering and abstract details of instruction handling.

_file_objects

• [ ] completion

The main problem with the way that the _file_objects module is being handled, is that it's largely unpacked and there are many things within it. The vast majority of the public-facing API of Scrivid comes from the _file_objects module. However, everything is referred to in an unpacked way. So, instead of, say, _file_objects.RootAdjustment, it's simply RootAdjustment.

While this saves on typing, this is a very scattered approach. So, instead, I'd like to compress this into more appropriate 'categories', and change various names to match.

The structure could look something like this:

scrivid
 ├── adjustments
 │    ├── core
 │    │    ├── HideAdjustment <*1>
 │    │    ├── MoveAdjustment <*1>
 │    │    └── ShowAdjustment <*1>
 │    ├── hide
 │    │    └── create() <*2>
 │    ├── move
 │    │    └── create() <*2>
 │    └── show
 │         └── create() <*2>
 └── reference
      ├── core
      │    └── ImageReference <*1>
      └── image
           └── create() <*2>

** notes* [1] The respective submodule core would be where the classes themselves are stored. [2] The create() function would be the factory function for the respective object.

[trystyncote]

The way I see it, in order to best facilitate this change, it would be wise to restructure how the code is meant to behave. For instance, the abc module defines how an adjustment abc.Adjustment or qualm abc.Qualm should be defined. In order to best accommodate for customizability, the project needs to be restructured to allow this to work smoothly. For instance, since abc.Adjustment has activation_time as an abstract method, it's safe to assume that all adjustment objects will be able to call activation_time and get an integer, representing time, back. Therefore, it can be called to signify when the adjustment activates. I think the same philosophy applies here, and how it's actually structured may influence how the object-calling works, as per this issue.