Nice to see your fast progress on the crate filter (y)
* Each crate can contain other crates AND tracks.
This means that in the example above if you have songs inside the
Progressive crate,
there is no way to see them alone, you have to see them with the nested
instrumentals as well.
This is because when you want to see what progressive songs you have you
don't care if they are
instrumental or not. If you care, you should have another crate inside
Progressive that's for
the songs that have lyrics.
Just to make sure I got you right, with a Crate-Tree like this (and things with
+ are songs)
/Metal
+ UnsortedMetalSong
/Metal/Progressive
+ NonInstrumentalProgressiveSong
/Metal/Progressive/Instrumental
+ InstrumentalProgressiveMetalSong
If I select /Metal from the TreeView I will see all three Songs, Selecting /Metal/Progressive will
show "NonInstrumentalProgressiveSong" and "InstrumentalProgressiveMetalSong"?
On a first glance that makes perfect sense.
But I'd like to be able to view only the 'UnsortedMetalSong', for sorting it
further down into the tree-structure (when organizing my library).
Maybe a Checkbox above the TreeView "Show titles in child-crates", ticked by default,
would work for that. Like that one would be able to see all Metal stuff (default) and also only
those that are direct children of "/Metal" (not in child-crates of /Metal).
The crate: filter would work like this:
** If you want to see all instrumentals you type crate: instrumental
and you get both /Metal/Progressive/Instrumental and /Rock/Instrumental.
** If you want only Metal instrumental songs you type crate: metal crate:
instrumental
and you get only /Metal/Progressive/Instrumental songs.
That also makes sense. What about an additional absolute filter-syntax like
this:
- "/" and "*" are not allowed in Crate names.
- if no "/" nor "*" are in the query, search as you do above (find crate in
hierarchy that matches by name)
- allow 'absolute' searches in crates, like in a unix-file-system (starting with or
containing "/")
- use "*" as a wildcard for subcrates and songs on the way
- if there is no "/" at the start of the search-query, treat that as a "*"
- crate: /Rock will show items in /Rock but not sub-crates
- crate: /Rock/* will show items in /Rock and all child-crates
- crate: /*/Instrumental would find all Instrumental songs no matter what
Genre they are in (if Instrumental is always the last layer in the tree,
otherwise use /* at the end).
- crate: Alternative/Instrumental/* would find all alternative instrumental
songs no matter the genre (assuming the naming-structure you used above)
For me (coming from a Unix Filesystem-view) that looks super intuitive. It does
not allow to search for terms that are in different order in the path as your
suggestion (thats why I would treat it as an extension to it):
- /Metal/Alternative/Instrumental
- /Rock/Instrumental/Alternative
can both be matched by crate: Instrumental create: Alternative, where a
path-matching syntax looks weird.
Are there other people that could imagine crate-structures that would profit from those wildcards? Maybe we
need a "**" wildcard to match any subcrate-path (including "/") and titles, and
"*" to only match direct subcrates.
Anyway: That's maybe out of scope for your GSOC work atm? And could easily be
implemented in a second step. But I think that your idea of naming crates and
their position in the tree via paths would lay a great ground for such a filter.
Keep up the good work for mixxx!
Cheers,
Markus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
