Problem:
1. If a toolbar is docked and hidden, when config is written, dock is set to 0 (undocked).
2. When config is read, if a toolbar is docked, then the show field is ignored, and the toolbar is always shown.
Summary of fix:
1. Introduce a new version of the dock field (DockV2) to minimise the problems when running previous versions of Audacity, having run a version with this patch(as suggested by Paul).
2. In ToolManage::WriteConfig, for a docked toolbar which is hidden, DockV2 is set to the dock number, and not 0.
3. In ToolManager::ReadConfig, for a hidden docked toolbar in the config, the toolbar is docked, but is not included in the configuration.
Note, that if a version of Audacity without this fix is run after running a version with this fix:
1. The dock of each toolbar is reset to its default value.
2. In addition, for 2.1.3, 2.2.0 and 2.2.1 whether a toolbar is shown or hidden is reset to its default value.
This reverts commit 048c1b8c5a.
I observed that it was not all right if you switch between Audacity versions, as
some cautious upgraders might do:
Delete audacity.cfg.
Open 2.2.0 and quit.
Open 2.1.3 -- and observe that the scrubbing and combined meter toolbars appear,
one over the other, at top left. Combined and separate meter toolbars are not
meant to appear at the same time.
Quit 2.1.3 and open 2.2.0. Now those two toolbars appear at some other random
seeming positions.
Summary of fix:
1. In ToolManger::WriteConfig, for a docked toolbar which is hidden, the dock number is not set to the dock number rather than 0 (undocked)
2. In ToolManger::ReadConfig, for a hidden docked toolbar in the config, the toolbar is docked, but is not included in the dock's configuration.
... Only the case that you click the grabber and release, or you drag the
toolbar ending in a docked position.
Doesn't work yet when drag ends un-docked.
... 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.
