Bugzilla – Bug 643
Residual consistency issues with SHIFT showing Loop Play button icon.
Last modified: 2018-08-20 11:45:16 UTC
These are agreed residual issues remaining after resolving bug 307 "SHIFT key makes Play button display as Loop Play". 1 User sees the Play button change to Loop Play not just on holding SHIFT but on holding SHIFT with other modifiers e.g. CTRL + SHIFT. They could wrongly get to think that CTRL + SHIFT + SPACE does loop play. 2 The Play button has no separate icon for Cut Preview (hold CTRL and click Play. 3 The Record button has no separate Append Record icon, therefore a user might surmise that SHIFT + R does not modify recording behaviour. James wrote: > If someone wants to design and get an icon agreed with everyone for cut-play > and append-record then I'll put in the logic to just show the right icon when CTRL > or SHIFT is pressed, and default when both or neither are pressed. > > 16x16px PNG files preferred. > > If the desired icon will appear as an overlay on top of the standard button, this should > be submitted as an overlay. Possibly point 3 above has other considerations attached to it that mean it's deemed not necessary to fix it for this bug. Steve (-devel) and James (off-list) suggest that if we had a consistent way of indicating which tracks were to be recorded into e.g. selectedness, we don't necessarily need Append Record. I don't think we are ready to go that route until we have overwrite and insert recording, but if we do get those features, we may want a separate record icon for one of those.
Created attachment 503 [details] Partial fix, for Transport Play button only. Had to define two new button images (for cut preview play, and disabled version of same). Open to other opinions about the artwork.
Created attachment 504 [details] Extends previous patch to affect transcription play button analogously. Includes all of the previous patch. Moved event-handling code for the change of Play button appearance out of class ControlToolBar and into class AButton, which should be a useful preliminary to making the Record button also change appearance in response to Shift. Extending the scope of this issue, I think the other play button in the Transcription tool bar should be more analogous to that in the Transport tool bar. So now that button also changes appearance for shift and control, and also is disabled when recording. Play at altered speed may also now loop or make a cut preview. Two new commands are added in Menus.cpp which may be bound to keystrokes, like the existing Play At Speed command.
Another question: what should be done about tool tips for the two Play buttons? That for Transport indicates two of the three key bindings, for ordinary and looping play, but not for cut preview play. That for Transcription (which also has three way behavior, with my second patch) makes no mention of key bindings. Inconsistency and incompleteness.
(In reply to comment #2) > Created an attachment (id=504) [details] > Extends previous patch to affect transcription play button > analogously. > Includes all of the previous patch. OK so on that basis I clicked the "Details" link for the first patch and obsoleted it, so it is simple for a visitor to know which patch to apply. (In reply to comment #3) > what should be done about tool tips for the two Play buttons? That for > Transport indicates two of the three key bindings, for ordinary and > looping play, but not for cut preview play. I haven't tested your patch (and won't be doing so until after 2.0.6) but I would expect the Transport Toolbar Play button to only change to Cut Preview icon when there is a selection in the track. I would assume we would have to include the Cut Preview shortcut in the tooltip. What about the "Play()" in that tooltip and also the "Stop()" tooltip? It's "correct" given by default that "Play" and "Stop" have no binding, but doesn't let people learn that Space does Play/Stop. Would it be reasonable for that tooltip to take the binding for "Play/Stop" if "Play" and "Stop" respectively did not have an assigned binding? > That for Transcription (which also has three way behavior, with > my second patch) makes no mention of key bindings. I think we've agreed to add bindings to tooltips as and when an opportunity arises, so I am OK with it, but by default it would only show () because there is no default binding for it.
(In reply to comment #4) Perhaps the consistency of tooltips across toolbars is a bigger problem than just transport and transcription and merits another Bugzilla entry. Why not make have all tooltips indicate keyboard shortcuts when defined?
(In reply to comment #5) Paul L wrote: > Perhaps the consistency of tooltips across toolbars is a bigger > problem than just transport and transcription and merits another > Bugzilla entry. Why not make have all tooltips indicate keyboard > shortcuts when defined? I'm fine with your opening a P4 issue for it. I still think the default Play( ) and Stop( ) tooltips are a problem. Until you look at the Transport Menu, those tooltips could mislead users into thinking there is no shortcut to play or stop. Obviously we could add "Play/Stop" (Space) to tooltips for both buttons but then the tooltip is getting large. Is there an OS size limit for tooltips?
To do everything we would need a different design rather than tooltips, as there is more to say about PLAY and RECORD than we can reasonably put on a tooltip. The OS limit for tooltip length is way longer than is useful. I would not support us mentioning more than three features in one tooltip. Even if some people do read it all, I believe it would inhibit the majority of people from reading any of it, and it would look messy, so would be a net loss. I would not support adding information about SPACE to the tooltip. Our 'discoverability' requirement does not require that we can find out about every related feature by every related route. So, for example, if SPACE can be found out from keybindings, and it can, that is enough to satisfy 'discoverability'. So, I would say leave SPACE out of this bug, and lets focus here on consistency, per bug title, and be selective in what gets on the tooltips. Then use (e.g.) http://wiki.audacityteam.org/wiki/Proposal_Smart_Help to discuss a smart help mechanism that gives us more room and opportunity to give more information in context, and it should apply to buttons, preferences, menu items. It will need careful design.
(In reply to comment #7) James, leaving aside the special complications for play and record (and, transcription play) buttons, I just want to raise this simple question: If, say, :Skip to Start (Home)" appears as a not overlong tooltip, and updates appropriately if you bind some other key to the command -- then why not do similar for the buttons for cut, copy, paste, zoom to fit, etc.
Paul, showing key-bindings in tooltips for buttons across the board is indeed consistent. I prefer cut, copy, paste button tooltips without the key bindings. Personal preference here. I would prefer the larger buttons be like that too, except that the added complication of 'play' and 'record' needing SHIFT to activate the alternative mode is some justification for showing key bindings. One can argue that big buttons have key-bindings shown and small not is a consistent policy.... When I wrote comment 7 I hadn't realised that the tooltips had 'Play ()' and 'Stop ()', i.e. that they already had a () for the keybinding (Space). Given that, I no longer am against the () changing to (Space). It is an improvement. It makes more sense than an empty bracket. I would like to increase clarity about how this bug can be closed. For me, the key bindings in tooltips part of this consistency bug can be closed by any of: - Ensuring all six large-button tooltips show key-bindings. - Ensuring no buttons have keybinding tooltips. - Ensuring large and small buttons have keybinding tooltips.
(In reply to comment #8) Actually, with my own keyboard preferences, the tooltip for Play includes "(Space)" but that for Stop includes "(/)". Are you aware that there is a command in keyboard preferences for Stop only, distinct from the start-or-stop bound to spacebar? It's that binding that is shown for the Stop button. So "()" is shown when key binding is possible but there isn't any, as is the default for the Stop command that is also associated with the Stop button. It is not meant to mean "(Space)". Showing nothing at all when there is no key, instead of empty brackets, may be the improvement. I might have enlarged the scope of this discussion beyond what was intended when the issue was opened. Maybe another Bugzilla entry just for this tooltip consistency question is appropriate.
(In reply to comment #10) > Actually, with my own keyboard preferences, the tooltip for Play > includes "(Space)" but that for Stop includes "(/)". That is because you added bindings for those when by default there is none. > Are you aware that there is a command in keyboard preferences for Stop only, > distinct from the start-or-stop bound to spacebar? It's that binding that > is shown for the Stop button. I was aware of that. > So "()" is shown when key binding is possible but there isn't any, as is the > default for the Stop command that is also associated with the Stop button. > It is not meant to mean "(Space)". Agreed, nonetheless in this case SPACE does "Play" (but also does "Stop"). Using "/" as separator in a tooltip when "/" can be a binding is perhaps suboptimal. One solution could be to use white space as separator: * Play tooltip could be "Play/(Space) Loop Play(Shift + Space)" * Stop tooltip could be "/Stop(Space)" Or some other way of indicating Play/Stop is a dual binding. > Showing nothing at all when there is no key, instead of empty brackets, may > be the improvement. Yes, perhaps, though with no other contextual help system it could look odd to hover over the Play button with default bindings and see no shortcut for such an important action as "Play". > I might have enlarged the scope of this discussion beyond what was intended > when the issue was opened. Maybe another Bugzilla entry just for this tooltip > consistency question is appropriate. To me it would be "inconsistent" to have some tooltips show "all" their shortcuts and some show "not all". Tooltips are a high priority for me in Tools Toolbar because they have no other means of discovery in the main interface. And tooltips are obviously important in Transport Toolbar. So to be consistent I think that means all buttons should have tooltips (or some other consistent help system). Tooltips/Status Bar messages could be added to menu items too. Users could discover what "Find Zero Crossings" does, for example. With a more invasive help system there would have to be a preference to turn the visual help off. To avoid overlong messages, an indication that more bindings are available could be simply "...". But does that mean the tooltip and/or Status Bar would include a link? The question I have is - what other help system could there be for a small toolbar? There does not seem to be space for a Help button in e.g. Tools Toolbar.
Created attachment 508 [details] All the previous changes, and also new images for append-record. Append-Record with shift down now shows an image that combines the record and fast-forward images. Again, we can replace the artwork later. Disabled version of the image can be seen by pressing shift during a playback. Class AButton had been modified in the previous iteration of this patch to make it easier (as here) to make other buttons change appearence in response to modifier keys. Event handling code was moved out of class ControlToolBar and into AButton.
Created attachment 519 [details] The previous changes, merged with 2.1.0 source. 2.1.0 ready version of the previous changes.
(In reply to comment #13) Paul says this: * Changes transport play button image when Shift or Control is down, to indicate looping or cut preview play. * Changes the transcription play likewise. * Implements looping play-at-speed and cut preview play-at-speed commands. * Changes the appearance of the Record button when Shift is down, to indicate append-record. Given improved Play-at-Speed features are bundled, changed this to P4 Enhancement.
Committed by James, r13663.
Gale's original 1 & 2 appear to be fixed "3 The Record button has no separate Append Record icon, therefore a user might surmise that SHIFT + R does not modify recording behaviour. " We do indeed now have a modified Record button to indicate Append Record - and it properly persists while Append Recording is active (recording or paused) - but I still find it a poor icon that is hard to see and hard to comprehend.
(In reply to Peter Sampson from comment #16) > We do indeed now have a modified Record button to indicate Append Record > - and it properly persists while Append Recording is active (recording or > paused) - but I still find it a poor icon that is hard to see and hard to > comprehend. I agree - added Bug 1365.
