... in cases of "TranslatableString" that are not really translated.
This makes it easier to scan the code for such unusual constructions of
TranslatableString, distinct from mere mentions of the TranslatableString type.
... Trying to reduce that just to chained calls on S, or conditional and looping
logic for variations in layout.
Lift some declarations to higher scope; or use expressions that avoid local
variables; or even use lambdas for more complicated computation of arguments
for the member functions of S.
... It stopped doing so at 1c1aca5
Because the recreating of the ruler's button now happened earlier than for
the several toolbars, not later, but there was a side-effect on the theme
that the toolbar updates did, that the ruler relied on, namely the updating
of button background images.
Now ruler also invokes that step.
(But wouldn't it be better to do that update in just one place? I am not
sure what that place should be. ThemeBase::LoadPreferredTheme?)
ControlToolBar, after we make a system to register functions that calculate
necessary minimum widths for status bar fields.
Also let Scrubbing.cpp register its own strings.
Also be sure to size the status field sufficiently for "Playing at Speed".
... So that ControlToolBar::StopPlaying now does nothing directly to the
buttons, and can be moved to another place with no dependency on ControlToolBar
... This also causes a momentary push-down of the stop button, which happens
in ControlToolBar::StopPlaying, really to be visible, as was apparently the
intent.
For instance, when playing, then clicking in the quick-play ruler to restart
the play elsewhere.
... so most calls to ControlToolBar::SetPlay are removed. One remains in
TransportMenus, which will not be problematic for untangling dependencies,
and one remains where the toolbar remakes its own buttons.
But the routines that start and stop the streams, importantly, don't use it.
... Move that into ProjectAudioManager instead, and update the button, only to
reflect it, in idle time.
However, AudioIO also has its mPaused member variable, and it is not obvious
that it was always kept the same as the button state. No attempt was made
here to identify and fix any bugs, but only to preserve behavior.
See commit aeece118e8950d2aeee60ef4e1b2a2ee752129cd which changed it from
the original call intended to hide the quick-play indicator in case that is
how the play starts; but other things in that commit were sufficient to
guarantee that