View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001961 | MMW v4 | Properties/Auto-Tools | public | 2005-08-01 17:15 | 2005-12-18 09:48 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0001961: Mask improvements: more fine-grained control over folders | ||||
| Description | As described at: http://www.mediamonkey.com/forum/viewtopic.php?p=21079 , there's a bit of missing functionality and a bit of confusion in terms of MMs ability to control destination paths based on Folders. i.e. currently, we have the following controls: <path:n> - Path without the first 'n' Folders. <path:-n> - Path with only the last 'n' elements. The following issues exist, though: 1) We need a mask along the lines of <Folder> with the following functionality <folder:n> - Folder without the first 'n' directories. <folder:-n> - Folder with only the last 'n' directories. 2) In my opinion, <Path> mask includes Filename unnecessarily. i.e. the use of something like <Folder>/<Filename> would seem to accomplish everything that <Path> does, so why include the <Path> mask at all (in its current incarnation)--shouldn't we just change it so that it works without including the Filename element? (Alternatively, we could add a new <Folder> mask, but I'm not sure I see the purpose). Summary, we need new functionality and it can be added in 1 of 2 ways: a) add new functionality b) replace existing Path functionality Regardless of what we do, the online help needs to be updated as it is currently incorrect in how it describes the Path functionality. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 924 | ||||
|
|
Fixed in build 912. - I agree that <Path> isn't necessary now (because it's <Folder>\<Filename>), but due to simplicity and compatibility I left it there. |
|
|
Tested in 912 and the mask works however: The <Folder> Mask is missing from UI of the following dialogs: -Convert -Auto-Organize -Synchronization -Data burn I would suggest that as you recommended, that we retain the existing Path functionality, however, from a UI perspective, we should replace existing <Path> entries with <Folder> entries. |
|
|
I'd propose to leave it as it is now. The reason is that <Path> will be used more often, while <Folder> will probably be only used for some advanced/more complex cases. Thus, I believe <Path> will be easier to use for more users. |
|
|
I have to disagree with this one. To me, <Folder> is much easier to understand, easier to use, and more powerful. Easier to understand: because <Path> works for both folders and filenames which is confusing. Easier to use: because users aren't confused by the folder vs filename issue they use it in the manner that they'd expect (naming filenames independently of what originally appears (e.g. they may want /U2/The Joshua Tree, but they don't want Track_01.mp3, Track_02.mp3 etc.) More powerful: because they have the flexibility to name paths/filenames independently. |
|
|
Raising to 'immediate' since I believe this affects strings which we want to finalize this week. |
|
|
There's no need for string update, so decreasing priority. |
|
|
Fixed in build 924. - Implemented as suggested, hopefully this is what users would expect. |
|
|
Verified 926. |
