Browse view should have all the columns

[RAWRR]

This is an alternative solution to Bug #1228789.

The Browse view for folders is missing several columns that other views have. Most importantly, "Preview" and "Played" are very much missed.

I use Browse and Quick Links a lot in sets to cut down on how much scrolling I have to go through in the primary Library pane. Now that Preview exists I'd really like it to be there, and since I select tracks primarily from Browse it would be really helpful if Played was there too.

[jus (jus)]

The missing Preview column is already tracked in https://bugs.launchpad.net/mixxx/+bug/1160525.

Meanwhile, you can use the shortcut ALT+RETURN to load a track in Previewdeck and play (or assign your own key to keyboard/midi mapping) . This works in Browse mode too.
See http://mixxx.org/manual/latest/chapters/appendix.html#keyboard-mapping-table

[RAWRR (rawrr)]

A new thought about this occurred to me, which is that if the Browse view is only there because of Bug #952945, then Browse view may not be necessary at all once that bug is fixed.

However, the point of this post is this: If that is not true, if, for instance the Browse view exists to get tracks from perhaps removable media in a convenient way for live DJing, then that contradicts the idea that Browse view should not feature Preview and Played. If Browse exists to include tracks in a live set that cannot be imported to Library, then *any* track used in a live set should have all DJ-specific Library features applied to it.

Either the Browse view applies to live DJing, or it applies to Library import. Otherwise it is in some kind of weird limbo place.

[Daniel Schürmann (daschuer)]

For me, the browser view has two Main Use cases:

1: Play tracks that are not in the library folders. This might be the ~/Download folder or a jump drive.
2: View at your library like a file manager without actually open a file manager.
Sometime I can remember a track only from the place, where I have stored it.

Threre is also the pending question, which metadata should be displayed from track or from library.

Related:
Bug #1020438
Bug #1196311
Bug #909959

Conclusion?

[RAWRR (rawrr)]

TL;DR. (as usual) utmost apologies in advance.

D.S., both your 1 and 2 use cases apply to me as well.

 - In use case 1, presumably the act of playing them means you need them during a set. If played during a set, they need to be marked as played, and available for preview, and informative as to BPM. This applies even more when they cannot be found in Library - you need Played and Preview and BPM wherever you source your tracks.

 - In use case 2, I'm not sure what you mean "like a file manager". If you mean that the normal OS context menu is available, that would not be at odds with making Played/Preview/BPM available. If you mean with details and thumbnails view and stuff, we don't have that now anyway (we also don't have normal OS context menu for that matter), and still that would not be at odds with Played/Preview/BPM, or really the entire bank of columns that Library has, either.

 - As for metadata, it seems best to get it from the file itself, except as pertains to BPM (because it is absolutely mandatory, we can't risk relying on potentially haphazard id3 data for that) and waveform. Cover art is a grey area. I just keep my cover art in my id3 tags, personally. VirtualDJ doesn't need any huge database to create waveforms or BPM... I wonder how they do it.

If we had a rock-solid id3 editing engine built in, we might consider modifying files.

In the past and in other bugs we've gone so far as to discuss virtual folders in Library, and it got pretty fun with mockups and stuff (Bug #1228789). But while that may be useful and sleek, it still isn't as high a priority as providing missing functionality to places where tracks are going to be found in the middle of an actual set. Whether those tracks are just one or two missing from Library for whatever reason, or the whole collection, It shouldn't matter. Especially when you consider a circumstance like Owen described in Bug #1196311 where he (or the other guy, whatever) ended up DJing from some random external drive. They wouldn't have been able to preview unless they'd imported folders, something not likely to go smoothly during a set.

As for Bug #1196311, it wouldn't solve this bug. I'd see it as an extra feature for Library, maybe auto-read-new-drive-for-music-files; but it wouldn't obviate the need to dig around on your own home drive sometimes, unless Mixxx was doing some constant scan for music files absolutely everywhere it could find them... kind of a big job and probably messy? Doesn't seem worth it.

Then, as for Bug #909959, I don't know what inline folders would be. I seem to remember being able to navigate the folder tree on my Numarks and on my ion Discover DJ. I don't have them anymore so cannot test :/

[Daniel Schürmann (daschuer)]

> I'm not sure what you mean "like a file manager".

Just browsing the file systems folder.

By the way: Mixxx can display the native file picker dialog using the file menu. I have nearly missed it. Maybe we should hook it into the tree view as well.

[RAWRR (rawrr)]

I had thought of that being a cool possibility too, and would obviously be consistent with Browse as an in-program file browser.

Then I realized that there are many context menu items in Library (and that are also currently available in the context menu in Browse) which, like the needed columns in Library, are necessary controls/commands during sets.

So how about including the full Library context menu in Browse, but with a "nested" shell menu? The included attachment is a screenshot from WinMerge, which employs that arrangement ("right" and "left" in the menu refer to the two panes of that program). There is another program too that I use which uses that scheme, but despite wracking my brain can't remember the name of at the moment.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7028