Frames! What are they good for? (A refactoring story)

[bdshields]

The issue will track work involved to allow screens larger than the physical display.

20191104 - I'm narrowing down on two data types. One to describe the location and size of a widget and another to describe which part is visible. I'm slowly rolling this out across the widgets and I'm picking up on patterns of code that are ripe for optimisation (and simplification). I'm yet to act on these, but I'm not too far away. Interestingly, the code base is becoming smaller which will hopefully make my extensive changes more palatable.

20191103 - I want to refactor render_frame() to reduce the number of parameters, but increase the amount of data passed.

• {x, y} struct to indicate the origin <- This will drive the scrolling
• {width, height} struct to indicate size of frame <- child widgets need this info for their purposes
• {left, top, right, bottom} struct to indicate the visible part of the frame <- So that nothing is drawn outside of the frame. This will help with subframes.

20191101 - Reviewing how the rendering is conducted, everything seems pretty straight forward, but I now have a greater appreciation of the complexity of scrolling frames.

[bdshields]

Anyone interested in watching the development may do so here:
bdshields/lcdproc/feat/frame-scroll