View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002578 | MMW v4 | Properties/Auto-Tools | public | 2006-08-03 12:31 | 2007-01-28 17:54 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.5.3 | ||||
| Fixed in Version | 2.5.5 | ||||
| Summary | 0002578: Split path in Properties causes difficulty in copying stream properties | ||||
| Description | Currently file path is splitted in two fields in Track Properties dialog: 1. File path 2. Filename I find it quite a usability issue, let's say I have a stream address and want to copy&paste it to WinAmp. Then I have to take one part (http:/xxx.xxx/) and the second part (stream.mp3) and join them. I would suggest to show the full path in the first field (File path). Technical note: On a change of one string, the other would be modified and vice versa (because they would partically show the same info). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1013 | ||||
| related to | 0002162 | new | Users should be able to add/remove favorite radio stations |
|
|
Assigning to Rusty for a feedback. |
|
|
I think that the most common usecase by a long shot is when users edit _track_ properties, and for that scenario, the current implementation makes perfect sense, so we shouldn't make any changes for it. As far as the scenario you describe, I agree that it's confusing for the reason you describe: the user is unclear re. what to copy if they want to access the stream later on or in another application. The solution, I think, is to fix the second scenario only. I would argue for further simplification, though; for streams, it doesn't really make sense to talk about a Path and Filename, so why not just put the entire 'url' in either Path or File? i.e. why split them at all? |
|
|
Actually, as I think about it, it isn't related only to streams, but this is a small usability issue for any track. Let's say user is in Properties dialog and need whole track path, e.g. for usage in an external application. It's a problem then to get it, because it's split into two fields (unlike in the main window's tracklist). It's a minor issue, but I wonder whether it wouldn't make more sense to show full file path in 'File path' field, i.e. including filename. |
|
|
I have to disagree on this one. MM used to show the full path in one place and we changed it to make it easier more usable and I haven't heard anyone complain about this. As far as streams go, the _properties dialog should not even open for a stream_!! i.e. if the user clicks 'Properties' for a stream, a different dialog should open containing only the relevant properties, and presented in a manner that makes sense for a stream. |
|
|
Re. splitting of fields - I agree, it can be useful, but I think that the useful part is that user can easily access filename, i.e. it would still be possible to include filename also in the full path part. Re. stream properties - I don't think that streams are necessarily that different so that they would need another dialog, mostly setting of common track properties makes sense for them. Anyway, feel free to close this issue in case you don't think we can improve it anyhow, it probably isn't worth any longer discussion. |
|
|
I actually agree that this is an issue that we should resolve for 3.0. My only point is that we should resolve it without introducing other problems. So, wouldn't it be easy to just have a different dialog for streams? |
|
|
However, I don't think that another dialog should be introduced. Streams can represent many things (like radios, track samples, ordinary tracks, ...) and we can hardly say that user doesn't need some of the properties normally used for ordinary tracks. Not mentioning that it would mean another dialog to maintain, etc. |
|
|
So how about just putting the entire stream's path inside the 'Path:' field and not using the filename for streams? |
|
|
I'm still not sure, this is certainly an option, but I would prefer slightly my original proposal (i.e. to show _whole_ path in File path field and keep everything else as is). The reason is that although sometimes the filename part of streams (particularly for radios) looks like 'v128.mp3', for other stream it can have meaningful values (like artist-title.mp3) and in such cases the Filename field still makes sense. |
|
|
Sure, that's fine, as long as this change is _only_ for streams. |
|
|
Per IM discussion, the intent of the original proposal was to show full path but _not_ eliminate the 'Filename' field. Thus we'll go with the following in all cases: File path: C:\My Music\Track.mp3 Filename: Track.mp3 |
|
|
Fixed in build 1013. |
