... the bug was introduced at e581fa60d9328cc4c379f840a0cbd0a85179cad5
I think it is better to make TrackPanel::OnTrackMenu crash-proof when
called with the default argument
Fix:
Call TrackPanel::OnTrackMenu(Track *t) with a track pointer.
Query:
Is there any reason why this function's parameter has a default value of NULL?
... This seems the more portabe way to do it across platforms. We are not
relying on a passed-in TrackPanel, for the sake of keeping TrackInfo
independent of TrackPanel. We just get the active window from the
application, which should exists in all contexts in which the Settings are
demanded, which are drawing functions.
... Because of different ordering of file-scope static initializations, visiting
TrackInfo.cpp before wxApp is initialized. (This didn't happen on Mac.)
This requires other changes to PrefsListener so that safe unbinding is
guaranteed by destructors, even if the PrefsListener is destroyed after the
global wxApp object.
... It's not longer the largest then, though the remaining tangle may be the
most difficult. The seven are:
AdornedRulerPanel, ControlToolBar, ProjectAudioManager, ProjectWindow,
Scrubbing, ScrubbingToolBar, TrackPanel
The 17 that were freed are:
BackgroundCell
CommonTrackControls, TrackButtonHandles, TrackInfo (one component)
CommonTrackView
EnvelopeEditor
LabelDefaultClickHandle, LabelDialog, LabelGlyphHandle, LabelTextHandle,
LabelTrackControls, LabelTrackView (one component)
SelectHandle
SelectUtilitites
TrackArtist
TrackSelectHandle
TrackUtilities
... at last, making the TrackPanelCell objects responsible for both their views
and their hit-testing!
And leaving only one place in the code that defines the division of panel areas
into cells! Which is the collection of TrackPanelNode subclasses in
TrackPanel.cpp.
Now hit testing and drawing are sure to get the same rectangle, if that policy
for division into areas is modifed in just that one place. This should make
it easier to experiment with variations of that policy.
Note that not only cells have a Draw method, but cell groupings may also have
them, as for the yellow focus border, and the handles returned by hit-testing
may also do some drawing, such as for snap guidelines.
And 11 files leave the big strongly connected component. That leaves 13 in it.
... Problem involves sequence in which event handlers are done, and started at
commit 278509a which updated track Y coordinates in a handler.
Solution is to delay the updating of scrollbars further, using CallAfter.
Also remove one unnecessary call to ProjectWindow::FixScrollbars() because
ProjectWindow::HandleResize follows it and includes scrollbar update already.
... TrackPanelAx now sends an event to the project when track focus changes,
and TrackPanel listens for it.
TrackPanel also initializes TrackPanelAx with a callback to do the details of
rectangle calculation.
... The declarations in namespaces in Menus.h are gone, the function
definitions moved elsewhere.
So there had been hidden dependencies on the src/menus files, that
scripts/graph.pl did not detect. Now the lack of dependencies on those
files, according to the graph, is almost the reality.
EXCEPT that src/Menus.cpp still has extern declarations of functions defined
in src/menus/* that populate the menus, so things really are still tied up
in cycles.
Breaking that link dependency is one purpose of the future project of defining
a menu item registration system.
The graph as reported by scripts/graph.pl has only some minor changes. The
big s.c.c. grows again to 26, two new files in it, one file
(CommonCommandFlags) trapped in it again.
... not the best thing for the long term, but hidden dependencies on
TransportMenus.cpp are eliminated
Tying CommonCommandFlags again into the big component, which is now 26
