On 170606 14:23:07, Markus Klösges wrote: > 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 checkbox is a nice idea. Also yeah you got me right! > > 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) I think this is way too complicated for the purposes that crates serve. The way the crate filter already works is fine. Since the query uses the LIKE operator to find crates it is basically a wildcard. > 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. Since slashes will be in the names (but hidden from the user) the query you suggest SHOULD give you both - /Metal/Alternative/Instrumental - /Rock/Instrumental/Alternative If you want only one you can use crate: alternative/instrumental > Anyway: That's maybe out of scope for your GSOC work atm? I can look at it after I finish the crate rework. Depending on how stuff goes. ------------------------------------------------------------------------------ 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
