... if the event is not handled and skipped by sub-windows first, such as for
toolbar button clicks.
(But track panel clicks are skipped even after doing something, so they may
also cause seeking besides other responses. So click can seek AND set cursor.)
This is meant to make drag to seek and wheel for change of speed easier,
without needing to keep the mouse in the narrow time ruler.
Also lets you click in the ruler, then move in any direction, and not miss the
motion event that should start the scrub playback.
The event handling is a bit of a hack, using propagation. It does not use
capture.
The problem was that on Linux (not Windows or Mac) menu
events are generated when checking the menu items in
the toolbar menu.
Becuase of the recent changes I made and how the toolbars
are being shown (toggled) when the toolbar menu is checked,
they were simply being hidden. Actually, the were being
shown and then hidden because of the toggle.
So, with this change I made exposing toolbars a bit more
deterministic. The menus still use a toggle, but the
ToolManager now shows or hides the bars explicitly during
setup, so the menu toggle issue is resolved.
Previously there were three problems:
1) Docking marker calculation was relative to the mouse rather than relative to the top left of the dragged toolbar. On a big toolbar dragged from the bottom of the dragger that could be a long way off.
2) Docking markers appeared too low down. Their position was relative to the middle of the dragged toolbar. However as the toolbar may be resized on placement that does not make sense.
3) Large (Height()>120) toolbars could be thought to be too tall to dock in some places. The positioning code used their current size rather than their minimum size.
