Bugzilla – Bug 1554
Toolbars: open undocked if previously not shown, unless Reset Toolbars first
Last modified: 2019-05-12 06:15:17 UTC
See steps to reproduce. Note: if you delete audacity.cfg, open and close audacity, then in audacity.cfg, then dock=0 for these toolbars. Presumably the cause of the problem.
Changed title because far more general. Work around is to reset toolbars, set the toolbar you want shown before closing. This may now be a P3.
Regression on 2.1.2 though someone might think floating a "new feature". I suppose P3 is just about reasonable so added Release Note and full steps. This bug was already noted in bug 1500 for Scrub Toolbar only. Same on Linux so I assume "All".
(In reply to Gale Andrews from comment #2) > Regression on 2.1.2 though someone might think floating a "new feature". I > suppose P3 is just about reasonable so added Release Note and full steps. > This bug was already noted in bug 1500 for Scrub Toolbar only. > > Same on Linux so I assume "All". Thanks for adding the release note. The bug affects keyboard users and particularly blind keyboard users. For sighted keyboard users, they can't dock a toolbar, so need to know the work around. For screen reader users, there's the additional problem is that they won't realise that the toolbar is undocked, and will be confused that they can't find the toolbar by tabbing round the toolbars. (I reported the bug after a post on the Audacity4Blind list by an experienced Audacity user who couldn't find the combined meter toolbar.)
(In reply to Gale Andrews from comment #2) > Regression on 2.1.2 though someone might think floating a "new feature". I > suppose P3 is just about reasonable so added Release Note and full steps. I've changed it to P3. I presume you are OK with this change. > This bug was already noted in bug 1500 for Scrub Toolbar only. > > Same on Linux so I assume "All".
(In reply to David Bailes from comment #4) > I've changed it to P3. I presume you are OK with this change. Yes of course, the more so with your further explanation. I know I tried to change the "Importance" to P3 but must have mis-hit it. Given it is mostly an accessibility problem, I moved the release note into bug 33 and added the "Accessibility" flag.
Verified it still is a problem in 2.2.0 alpha.
Fixed at: https://github.com/audacity/audacity/commit/048c1b8c5a92e68ca9de67d25098400ab32ab68c
(In reply to David Bailes from comment #7) > Fixed at: > https://github.com/audacity/audacity/commit/ > 048c1b8c5a92e68ca9de67d25098400ab32ab68c In the commit message: "the dock number is not set to the dock number" should, of course read: "the dock number is set to the dock number".
Sorry David, I reverted the fix at https://github.com/audacity/audacity/commit/ecd149edadee0907b624b693bad8c71be89e7e7b We are in Beta test and this bug's priority is low, and I observed that the fix needs more work. Bad consequences this commit had: 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.
The problem with the fix is that it changed the meaning of the preference "Dock" but 2.1.3 still applies the old interpretation. The fix should be rewritten to put new information under a new preference key that older versions will ignore, with no effect.
(In reply to Paul L from comment #10) > The problem with the fix is that it changed the meaning of the preference > "Dock" but 2.1.3 still applies the old interpretation. > > The fix should be rewritten to put new information under a new preference > key that older versions will ignore, with no effect. Thanks for the suggestion. New fix in my fork: https://github.com/DavidBailes/audacity/commit/66f52449b6b13260d0df7426b74ea64d2e6c657f
Fixed at: https://github.com/audacity/audacity/commit/516af7178262b6448040fc22617c1935aea7e361
(In reply to David Bailes from comment #12) Tested on macOS 10.13.2 High Sierra with audacity-macos-nightly-2.2.2-63de7f0.dmg - 25.95 MB | version: 2.2.2--18Dec17 Now the previously un-shown toolbars open correctly in the tooldock areas a) Scrub Tool bar goes to the upper tooldock b) Spectral Selection Toolbar goes to the lower tooldock
Testing on James' 2.2.2 build of 18Dec17 on W10 As with Mac: Now the previously un-shown toolbars open correctly in the tooldock areas a) Scrub Tool bar goes to the upper tooldock b) Spectral Selection Toolbar goes to the lower tooldock
With the current fix it now causes a reset toolbar when reverting to 2.2.1 on MacOS 10.13.2. Should be reopened and fixed IMO.
(In reply to Cliff Scott from comment #15) > With the current fix it now causes a reset toolbar when reverting to 2.2.1 > on MacOS 10.13.2. Should be reopened and fixed IMO. As you can see from the commit message for the fix, I was aware of this side effect of the fix. My reasons for making the fix that I committed were: 1. To make the fix so there were less side effects when reverting to a previous version of audacity would involve having two properties for the dock number in the config file, and I wanted to keep the config as simple and obvious as possible. 2. The side effects when people revert to previous versions of audacity will fairly quickly go away as new versions of Audacity are released. And the side effect, although perhaps slightly irritating, isn't a major issue. 3. I was following along in the same lines as Paul, when he introduced the path property to replace the order property for the positioning of the toolbar. He didn't keep the order property to minimize side effects when reverting to previous versions of Audacity. As an additional minor point, if the old dock property were kept, then if a toolbar is hidden, then the old dock property would have to be set to undocked to keep versions 2.1.3, 2.2.0, and 2.2.1 happy, and so if ANY previous version of Audacity was opened and the toolbar shown, it would be undocked - which has similarities with the bug being fixed.
My only question is why we have gone from a very occasionally seen bug to something that happens every time one reverts to an older version for what ever reason. Seems as we've not really accomplished much this way. Of course as David said it will become less seen as we release new versions, but it seems as if there should be some way to fix it without this new issue. Anyway, just my opinion.
David's earlier iteration, which I rejected for 2.2.1, had this worse side-effect when you reverted to the previous version of Audacity: some toolbars appeared un-docked and sometimes at random locations. Be sure this worse side effect is not present. If I was careless about compatibility when I introduced the path property in an earlier version, well, it's because I've been learning too.
(In reply to Paul L from comment #18) > David's earlier iteration, which I rejected for 2.2.1, had this worse > side-effect when you reverted to the previous version of Audacity: some > toolbars appeared un-docked and sometimes at random locations. Be sure this > worse side effect is not present. > > If I was careless about compatibility when I introduced the path property in > an earlier version, well, it's because I've been learning too. If the consensus is that the current fix is not on balance helpful, then I'm quite happy to revert this fix, and perhaps look again at bug during a future release cycle.
I do not see any of the "worse side effect" that Paul mentions on MacOS.
(In reply to Cliff Scott from comment #17) > My only question is why we have gone from a very occasionally seen bug to > something that happens every time one reverts to an older version for what > ever reason. Seems as we've not really accomplished much this way. Of course > as David said it will become less seen as we release new versions, but it > seems as if there should be some way to fix it without this new issue. > Anyway, just my opinion. I've updated the fix: https://github.com/audacity/audacity/commit/cfdb7950f1cf455f2655769902b602b29c3e6f44 If you revert to an older version, the toolbar layout should now be unchanged.
Testing David's latest changes on macOS 10.12.3 with audacity-macos-nightly-2.2.2-f4c8920.dmg - 26.32 MB | version: 2.2.2--23Jan18 I get good forwards an backwards compatibility of toolbar layout's when repeatedly switching between 2.2.2 alpha and 2.1.3 According I am going to Mark this bug as resolved (as discussed with RM, Paul)
