On 06/06/2017 02:48 PM, Anast Gramm wrote:
I agree, the wildcards are overcomplicated and I don't think it fits very
well with how searches work otherwise. However, there should be a way to
search for only the tracks in a parent crate and none of its children.
Perhaps another special search operator could be used for this. For example,
if "^" was the search operator, crate:^Rock would show only tracks in the
Rock crate but not in any child crates. I don't know if "^" is the best
character to use for this, it is just an example to demonstrate the idea.
Using the above example crate hierarchy, crate:^instrumental would match all
the tracks in both Rock/Instrumental and Metal/Progressive/Instrumental but
none of their subcrates. If you wanted to query only one of those crates,
you could make the query more specific with either
"crate:^Rock/Instrumental" or "crate:^instrumental crate:rock".
I think that when someone searches for the Rock crate he wants to see all the
rock stuff.
Not just the ones that don't fall under a certain subcategory.
Besides there is the checkbox that was suggested earlier that the user can
check to get only
the tracks directrly hanging from the selected crate. It's intention is to help
user get organised.
After organization is done, I don't see any reason someone would want to filter
the tracks hanging
directly from Rock crate and not the ones in the subcrates.
Besides each song in a crate by definition also belongs on all the parent
crates.
A Rock/Instrumental is also just Rock.
If you follow the example of the main library feature in the redesign
branch, which generates search queries from what the user selects in the
side pane, you could make the checkbox work by adding the operator to
exclude child crates to the generated query. It would be nice if queries
from the crates feature could be saved and also viewed in the main
library feature. For example, a user could select crate Foo, which would
generate a query crate:="Foo" then the user could add another filter to
make a more specific query like 'crate:="Foo" bpm:>120', save that, then
recall it in the main library feature.
I think there should be a column added to the track table to list what
(sub)crates each track is in. If you are looking at the tracks that are
in a crate which has some subcrates, you may want to know which subcrate
a track is in. It would be confusing if you looked at the tracks in a
crate and all its subcrates then moved a track into a subcrate but did
not see any change in the track table. We can save this for later in the
project.
I am now starting to wonder if perhaps the crate feature and main
library feature should be merged. The crate tree could be a grouping
option selected for the side pane of the main library feature. However,
I'd be concerned that would be difficult to discover that crates exist.
Maybe there is code that could be shared behind the scenes, or maybe
that would be more trouble than it's worth...
------------------------------------------------------------------------------
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
