Element redesign

[jalovatt]

Some features, such as dynamic resizing and layer-based positioning, are currently impractical due to the elements being completely in charge of their positioning and size.

Problems

1. Elements are completely in charge of their position and dimensions
2. Elements have internal graphics helpers that work in pixel values
3. Window:update, and therefore the mouse state passed in to elements, has no way of knowing the position of a mouse event relative to its containing element
4. Some elements do important setup in their new or init methods that relies on their current dimensions (i.e. sliders' handles)
5. Some elements do logic in their draw methods (I think Label fading, for one)
6. The Window needs an onResize handler to manage the current scale (x/y should be separate)

Ideas

• Prior to doing anything else here, would it be preferable to work on separating elements' "theme" code from their logic?
  • If the classes can be structured so that a) their drawing helpers are only called from init or draw, and b) init and draw only have graphics code, then init, draw, and all of the helpers can be pulled out to a separate file
  • Will also require a UI-specific event on deletion to allow freeing up buffers, etc
  • Starting this refactor from a bare-bones UI similar to Eugen's template might make it easier to avoid mistakes/coupling.
  • Problem: Some elements' logic is tightly coupled to their UI implementation, such as text boxes determining the mouse position relative to their text.
  • A given class' theme modules could be required to implement the appropriate conversion functions themselves || themes could be required to expose the x/y/w/h of their "working" area.
  • Allow themes to specify offset x/y/w/h that are used for the element's logic?
• Give layers x/y parameters for blitting their buffers
  • Is there a performant way to manage their width and height based on their children?
  • Experiment with a Layer.getExtents method
  • What if elements prompt their layer to update its extents when they're added/removed/resized? (Would require a handler for myElement:setWidth(24) or something)
  • Alternatively, layer dimensions could be completely up to the scripter. If the layer has no dimensions, it could refer to the window's dimensions when needed
    • This might make anchoring very straightforward, i.e. `myElement.anchor = "top left" of its layer or window
  • How do we manage elements using relative coordinates when processing mouse events?
  • Have containsPoint return the position within the element that caught it (does it already do this?), then pass that back up to Window:update for inclusion in the current state
• Give layers a scale parameter (maybe separate scalePos and scaleSize to allow for resizing without moving, etc) that is passed to their elements.
  • Elements would need the scale when:
  • Drawing
  • Updating
  • Checking containsPoint
• Have elements use 0-1 percentages for as much of their graphics logic as possible (the Tab element's tab width and height, for instance) to make rescaling easy
• Allow Font.set to accept a scale parameter so that text can be resized as well
  • For performance, should probably process all loaded fonts' character widths at startup like the text functions do
• Would it be easier to have a separate DynamicLayer or DynamicWindow class with resizing already set up?
• What about having a native onResize method and just defaulting the scale parameters to 1, or short-circuiting if they aren't specified?