Adam Lovatt

- Elements should all have tests to make sure their Theme methods are being called.

A number of calculations are done on every update/draw/whatever even if the values involved don't change much, if at all. It may be worth sacrificing a small amount of memory...

An element class that accepts multiple child elements and acts as a container. - Handled by the GUI/layers/windows as a single element - Children are positioned relative to the parent....

Ideas that aren't feasible for 3.0. - [ ] Rotation origin - Doable with the built-in params, but it might be more workable to rotate from 0,0 and then translate...

For working with images from Reaper themes. - Inherit from or duplicate the Sprite class, depending on how much overlap there ends up being - Take pink/yellow into account when...

Could be done at the same time as extracting a module for class behaviors.

This could expand the existing function that fills in default props, making sure each prop is the right type and within any required ranges.

This might as well be its own module to make any future dev mode tools tidier to add. Could the debug grid be a hidden element/layer with its own checks...

- Getting/restoring settings from the GUI - Add a flag to elements if they shouldn't be stored? - Stringifying/parsing settings - Loading/saving to an ext state

Custom image + sprite functionality (i.e. implementing rotation offsets rather than using the awkward params in `gfx.blit`) isn't really practical without the ability to do matrix transforms.