0020964: Too much Tab key presses required to cycle all controls - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0020964	MMW 5	Main Panel: Toolbars & Menus	public	2024-05-30 18:44	2024-07-18 21:45

Reporter	zvezdan	Assigned To
Priority	urgent	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	5.1
Target Version	5.1	Fixed in Version	5.1

Summary	0020964: Too much Tab key presses required to cycle all controls
Description	Let say that I have program with the configuration that could be seen on the attached screenshot, having displayed the left side bar with the Tree and Preview panels, the right side bar with Playing and Lyrics panels and player on the bottom. If I am pressing Tab key, here are controls that will have focus: 1. active tab; 2. "+" button (added in 3027);; 3. left panel toolbar button; 4. List toolbar button (added in 3027); 5. row in Tree panel; 6. Tree panel menu button (invisible dashed outline for keyboard focus, added in 3027); 7. Preview menu button (added in 3027); 8. Playing/Selected arrow button (added in 3027); 9. Preview layout button (added in 3027); 10x. each field in Preview panel with Allow edits enabled, requiring several Tab key presses, depending of the number of fields that are enabled for displaying and the number of actually visible tags (added in 3027); 11. Play normally button; 12. Play shuffled button; 13. menu button in main view; 14. My Library button; 15. row in main filelist; 16. Playing menu button (added in 3027); 17. row in Playing filelist; 18. Lyrics panel (added in 3027); 19x. each enabled control in player (seekbar, Previous, Play, Stop, Next, rating, Repeat, Shuffle...). That is a way too much tab presses to cycle all controls. Suggestions: 1. "+" button in tab row should not get tab stop at all; that command has an alternative in menu (View / New tab), it is faster (less key presses) to open that menu by keyboard and choose that command from it, than to travel through all tab stops to reach that button. 2. List toolbar button should not have tab stop, it could be reached using the right arrow key after the left panel button gets focus. There is no point that that button gets tab stop, but not right panel button, or Search button. 3. Tree panel menu button should have displayed dashed outline when gets focus. 4. Playing/Selected arrow button and layout button in Preview panel should not get tab stops, they should be reachable by using left/right arrow keys after Preview menu button gets focus, just like you use these keys to move between toolbar buttons in the main toolbar. 5. It is good that you have added Preview and Lyrics panels for tab stop, but it is too much using tab for every field in Preview; after any field in Preview panel gets focus, the tab key should not be used for changing focus to another field, but up/down keys, just as you move between rows in filelist. 6. Play shuffled button, menu button and My Library button should not have tab stop, they should be reachable using left/right keys after Play normally button gets focus. 7. Almost all player buttons have their alternate options in the main menu, and again, it is faster to open Play menu by keyboard and choose required option from it, than to cycle through all tab stops to reach the same command in player. The only controls in player that require tab stop would be these that don't have alternatives in main menu, like seekbar, rating and volume bar.
Tags	No tags attached.
Attached Files	Too much Tab key stops.png (288,034 bytes)

Fixed in build	3036

rusty 2024-05-30 21:09 administrator ~0075648 Last edited: 2024-05-31 16:14	This is mostly covered at 0020933, albeit from a slightly different perspective. What you're currently seeing is a partial implementation of 0020933 1. Agreed--as described at 0020933 issue 2), arrows should be used once the user TABs to the tabs. 2. Yes, it probably makes sense to use arrows to navigate within Toolbar elements. [EDIT: this is mostly implemented, except for a bug in which TAB also stops at the view selector / Playing menu] 3. Agreed--there should be a way to see when the Tree's menu (ellipsis) is highlighted. [EDIT: this is just a bug in which a) the menu is highlighted after the tree rather than before b) the highlighting is 'invisible' or may not work] 4. Agreed--arrows should be used to navigate between controls in the Preview window [EDIT: this will be implemented slightly differently depending on whether or not EDIT mode is enabled.] 5. Agreed--same as above for the Lyricss 6. [EDIT: Ignore this comment--it was a misunderstanding] I'm not clear on what you're suggesting here about Menu/My Library. As far as TABbing between player controls, it's a bit tricky since there are a couple of groups: - back, play/pause, stop, next - ratings - repeat, shuffle, equalizer, speed, cast - volume I suppose MM could TAB between each of the groups, and use Arrows within the groups. 7. OR, as you suggest, focus on the Player can be eliminated entirely, but I think I'd prefer to try the approach at 6.

zvezdan 2024-05-30 21:34 updater ~0075651	6. I am talking about Play normally, Play Shuffled, three dots menu button and My Library button in the main view next to the artist name when the Info panel element is enabled (it could be seen on the screenshot). It is too much to cycle through all these buttons with Tab key, they should be reachable using left/right keys after Play normally gets focus. 7. I wouldn't eliminate focus on the player entirely, but only for these commands that have alternatives in the main menu (Play, Next, Shuffle, ...), However, I would leave tab stops for seekbar, rating and volume bar since these don't have alternatives in the main menu.

rusty 2024-05-31 16:20 administrator ~0075660	6. Agreed that Arrows would be preferable to TABs for navigating info panel buttons. This may not be possible in the short term. 7. I disagree with the approach of disabling some elements from the tab order, since it'll be unexpected to the user. 8. Arrow handling needs to be implemented for the custom toolbar (off by default) 9. Ideally, for the Player, it should be possible to use the same approach as the Preview window (arrows within, and ENTER to change Ratings/Volume), BUT it may not work correctly depending on the order of controls in a skin, and it would require that skins be updated to include the ability to define control order.

zvezdan 2024-05-31 16:53 updater ~0075661	I think it is pointless to have Tab key pressed 19+x times, just to reach to some control in player (where the x is the number of fields in the Preview panel and number of displayed controls in player). And if you have some even more complicated layout then that that is shown on my screenshot, e.g. having opened popups or other view elements, you will get even more tab stops to travel until you make a full circle. If we forget the hotkeys for a moment, it would be much faster to press Alt+P to open the Play menu and press the down key several times to reach the wanted command than to press Tab key 19+x times. I suppose that the order of controls in player is equally significant not only if you want to use left/right keys, but also for Tab key.

rusty 2024-05-31 18:18 administrator ~0075667	We all agree that the number of TAB presses should be limited. It's just a question of balancing the work/risk with the desire to release a stable version of MM 2024 asap--the fact that we're using Chromium under the hood makes this non-trivial.

michal 2024-07-14 07:39 developer ~0076280	Resolving, as the main cause - Preview panel - was fixed as 0020443. The rest is part of 0020933.

rusty 2024-07-18 21:45 administrator ~0076336	Verified 3037. Remaining issues (to be tracked within 0020933 are: 1. The '+' Tab still requires TAB (unlike other tabs which use ARROW). 4. Playing/Selected arrow button and layout button in Preview panel should not get tab stops, they should be reachable by using left/right arrow keys after Preview menu button gets focus, just like you use these keys to move between toolbar buttons in the main toolbar. 6. Navigation of buttons (Play, Shuffle, Overflow) in views that have the Info Panel element enabled should be able to use ARROW like other UI elements within the view. 7/9. Within the player there may be room to replace TABs with ARROWs except before each control that requires ARROW keys. 8. Custom Toolbar: ARROWs are now implemented, but so are TABs!