View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0020473 | MMW 5 | Main Panel: Toolbars & Menus | public | 2023-12-13 20:41 | 2024-03-31 10:31 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.1 | ||||
| Target Version | 5.1 | Fixed in Version | 5.1 | ||
| Summary | 0020473: Context menus are selectively disabled for inaccessible tracks | ||||
| Description | Very often, upon right-clcking a networked track when the network is inaccessible, some contextual entries are disabled (e.g. auto-tag) but others aren't (e.g. Play now). It's quite confusing since some of the menus seem to indicate that the track is accessible, but others indicate that it isn't, so it's unclear what the situation is (it took me several minutes to figure out that the reason for the failures is that the network wasn't accessible). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2829 | ||||
|
|
Seeing that the disabled items was a purpose of 0019108 I wonder what you are suggesting? A) Revert fix of 0019108 and always enaable all items B) Disable just items that needs the file access, e.g. 'Play now' disabled and 'Queue Last' enabled? C) Disable all items for inaccessible file ? I guess that B/C would still result in a confusion why some items are disabled and the others are not... And supposing that inaccessible tracks can be still part of a multi-selection (with a mix of accessible/inaccessible tracks) then just enabling all items again (A) would make most sense ? |
|
|
What was confusing to me was that _some_ items were enabled and others weren't. BUT, I think it makes sense to leave actions enabled if they work and for non-functional actions to be disabled. I suppose that the issue is that there's no indication in the UI that items are inaccessible. Would it make sense/be feasible that when the user selects items that if they're inaccessible, they appear greyed out? That way we could take approach B) and there would be no user confusion. OR if a location is disabled/inaccessible, why not just pre-emptively grey out all the tracks from that location? Note: I suspect that the above suggestions might be risky--if so we should push this. |
|
|
Good point, the inaccessible items should be shown as greyed out, currently they are shown as greyed out only after an attempt to play them.. Fixed in 5.1.0.2828 + taken the approach B) |
|
|
On 2828, checking for networked files on a unavailable NAS: 1) Play Now is enabled. 2) All file show as accessible, instead of greyed out when initially opening list. Eventually some files start showing greyed out. This seems to be triggered by using Context Menu on these files. |
|
|
1) Yes, Play now is enabled as e.g. for http links it is time consimung to find whether the file is accessible for playback 2) Yes, the accessibility is now checking just for right-clicked file (if context menu is opened) But, because it would be time consuming to chech accessibility/deadlinks for all tracks in a large list and because a list can always include mix of accessible/inaccessible tracks it makes the most sense to revert 0019108 so that all items in the menu appears enabled.. This way user can run e.g. 'analyze volume' action on mixed selection of accessible/inaccessible files and those that are inaccessible are just skipped. => Fixed in 2828 |
|
|
Verified 3010 Tested all cases and for me it works logically now. |
