View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017633 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2021-03-05 03:18 | 2021-06-07 08:44 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.1 | Fixed in Version | 5.0.1 | ||
| Summary | 0017633: 'Unsaved image' label / format in Add cover dialog should be clearer/more informative | ||||
| Description | When the user adds/edits artwork in the Properties dialog, the labels associated with the artwork are unclear in some cases. i.e. 0 Select tracks from an album 1 Right-click > Properties > Artwork > Lookup image 2 Select an image and press OK 3 In the Add Cover dialog, choose 'Save image to tag, otherwise save to file folder' and click OK --> Image appear as 'Unsaved image' This is confusing because it's the same message that appears for automatically-looked-up artwork, even though they're handled completely differently i.e.: a) artwork that's automatically looked up should only be saved if the user consciously decides to save it b) artwork that has been manually looked up in the current Properties dialog session should be saved (either to the tag or to a folder depending on what the user chose) as soon as the user presses OK. Following internal discussion, we agreed that the current behavior in which the image changes aren't saved until the user clicks 'OK' in the Properties dialog is fundamentally correct, but that messaging to reflect this can be improved. We agreed that there are three categories of images, each of which should be labelled differently, and have different associated actions: 1) auto-looked up images: label:'Unsaved image' |buttons:[Save] (no [Delete] because it'll just get looked-up again). Clicking 'OK' in the Properties dialog has no effect unless the user first clicks the [Save] button to 'Add cover' for this image, in which case its status changes to category b). This is already implemented. 2) images that have been updated via 'Add Cover' _during the current Properties session_ (either via 'Lookup image' or [save] button): Currently such images are labelled 'unsaved', but the following would be preferable: label:'Save to X' (for 5.0.1, "" for 5.0.) | buttons:[Delete]. Clicking 'OK' in the Properties dialog during the current session causes such images to be saved to their chosen locations. If they press 'cancel' then such images revert to their previous state (i.e. either non-existant, or 'unsaved' (in the case of auto-looked up images). 3) images that have been previously saved: label:'Saved to X' | buttons:[Delete]. This is already implemented. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2400 | ||||
| related to | 0017630 | closed | michal | Properties: Editing linked artwork causes failed artwork updates (linked and tagged) |
| related to | 0017639 | feedback | rusty | Add cover: artwork format is always saved as thm in cases where artwork is in the directory but not in MM |
| related to | 0017988 | closed | michal | Right click/Paste Artwork in Properties > Artwork causes AV (regression in 2411) |
|
|
2) fixed in build 2319 (5.0 version) |
|
|
This bug originally described only changes to the image label for unsaved items in category 2) above. Upon further discussion it became clear that the confusion about image formats is closely related to 0017639/0017640. So for the purposes of the remaining work in this bug: - 0017639/0017640 will cover the cases in which artwork is saved to an incorrect format - this bug will describe how MM will improve communications to the user especially in cases when MM saves to an _unexpected_ format Workflow assumptions are that: A) The Add Cover dialog defaults to the a location/format chosen in Options > Tags and Playlists > Image location B) The Add Cover dialog prevents the user from choosing the 'First image' format in cases where: - all files in an album are not selected/checked for application of album art - files from more than one album are selected - selected files are in a directory containing more than one album C) The Properties > Artwork tab will display the 'currently recommended' format based on the checkboxes selected at the time and based on the rules above (B) With the above in mind, the UI changes for 5.0.1 are that for category 2) images the label should communicate: 'Save to:' <imageformat>. <reason why image format doesn't match the format chosen in the Add Cover dialog> e.g. after the user clicks chooses artwork on the 'Add Cover' dialog, the Properties > Artwork image labels would be updated to show expected artwork status based on what tracks have been selected. e.g.: Save to: folder.jpg Save to: <album>.thm. 'folder.jpg can can only be used if applied to all files in a directory that belong to one album.' The approach conforms with the intentions described in 0007070. i.e. any time a directory is subsequently scanned and generic artwork exists (e.g. folder.jpg) it will get re-associated with all files in a directory, and MM should therefore assign such generic artwork in cases where it makes sense. A second benefit is that it prevents such cases as described at 0017640 in which one file of the album has folder.jpg, which is problematic if the user edits folder.jpg for other tracks on the album. |
|
|
Original issue fixed in build 2400. The remaining part (text with reason) will be discussed and solved in 0017639. |
|
|
Verified on 2410 |
