FLTK manages window resizes itself, but not text or some user drawn graphics. Our resize code fills in these elements.

It closely follows the context idea that the rest of Yoshimi uses. The way this operates is as follows.

Triggering is derived from the 33mS FLTK wait(0.033333) call. This is passed to the normal update code in "MasterUI". This procedure ensures that there will usually be a steady 33mS between GUI actions, resize tests and redraws, thus reducing processor loading.

When "MasterUI" first gets the call it passes it on to all the other top level windows in sequence, but *only* if their size has actually changed. It then passes the call unconditionally to the other main areas, PartUI and BankUI, and finally runs through its own objects.

Part and Bank will themselves portion out calls to subsections depending on whether they can be dealt with directly, or have to be passed further down the stack. For an extreme example, the Amplitude Freemode window in Addsynth Voice has to unconditionally receive this call. It's complete route is:

main->Master->Part->PartEdit->AddGlobal->AddVoice->AddEnvelope

If a window is visible, and it's size has changed it will then perform the actual text font resizes, then mark itself as 'seen'. Font sizes are calculated from the ratio of the current window size against the window's default size, and the font itself multiplied by this scale factor. Fonts are defined as integers so will visibly step up and down in size. Other drawn elements will change smoothly.

Usually only one window at a time will be changing, so apart from the tests made on the way, there is little extra work.

The FLTK file chooser proved intractable so has been replaced with our bespoke file chooser. This actually has other benefits, being tailored to our exact requirements.

We have also implemented our own code for the 'Alert' and 'Choice' operations.
