Request: Options>Library>Search>Search current view: Option to disable

[drakinite]

Hi,

I've found the automatic search from typing in-view quite annoying, because I've often accidentally pressed the wrong key, making the entire UI go crazy while it switches to a search view. It's especially annoying since it's laggy, lol.
I'd greatly appreciate it if there was an option to disable the type-anywhere-to-search — Possibly a dropdown option of "Do nothing", but preferably a checkbox to the side to disable it.

Thanks

[Ludek]

If you accidentally press a letter then you can immediatelly press Esc or Del to cancel it, doesn't this work for you?
You could also change to 'Scroll to matches' to perform power scroll (like in MM4). Just there have been some regressions related to power scroll (that I fixed for 2273).
Re lagging: I cannot replicate. In which view you are testing? Can you catch this in a video?

[drakinite]

Pressing Escape to cancel does work, but the issue I have is the entire view changing when I don't intend it to. I have changed to "scroll to matches", which is better because it doesn't cause any delay/lag; but it's still frustrating to have to press escape again.

I recorded my experience and more clear explanation here: https://youtu.be/BHxA4VlJpTQ
I primarily use MM in the list view, and I'm using build 2273 (from Wednesday evening)

[Ludek]

OK, I understand now based on your video.

When you are in Music node then yes, pressing any key works like global search of the whole collection.

I was testing [Music > All tracks] node which is just filtered by the searching phrase (without changing the view).

Maybe the Music node in 'List' view should behave like [Music > All tracks], and maybe also the 'Take no action' should be an option for typing in a view. We will discuss and review. Thanks for the feedback and enjoy the weekend!

[drakinite]

You too!

[Barry4679]

I was testing [Music > All tracks] node which is just filtered by the searching phrase (without changing the view).
Maybe the Music node in 'List' view should behave like [Music > All tracks], and maybe also the 'Take no action' should be an option for typing in a view. We will discuss and review.

Maybe I misunderstand what you wrote?
[Music>AllTracks], and also [Music top node] in List View, work fine for me. ... ie. they filter without changing View

But doing the same thing from EntireLibrary, or one of my custom collections, does the annoying View change when called from the top of the node in View mode, but it is OK from the AllTracks sub-node.

IMO the only acceptable behaviour is the current behaviour in the Music node ... ie. no switching to Browser view ... a black and white situation from my POV

and maybe also the 'Take no action' should be an option for typing in a view. We will discuss and review.

I didn't like the existing behaviour when I first saw it, but now think that it is one of the better things from the MM5 changes.

Maybe the option that you could introduce would be to only action the filter, or scroll-to, once the the Enter key is pressed (ie. inside the Context Search control). That may be enough to handle the situation the OP is finding unhelpful. ... It may also make MM5 perform better on slower PCs ... ie. don't jerk the screen around until you are sure that the user has completed entry of their filter criteria string.

The other thing that you may notice from his Video is that he had the Column Browser open, with an active filter criteria, when he (accidently) typed the contextual filter string. ... what happens in this situation is that the new contextual criteria replaces the active Column Browser, rather than being additive. ... ie. he was filtered to a specific artist (via Column Browser), and then he filtered more (via the Contextual Filter facility) ===> you bounced him out of the artist he was filtered to, and showed him tracks from any artists ... that will never be what the user is trying to achieve ... can it be fixed?

[drakinite]

Maybe the option that you could introduce would be to only action the filter, or scroll-to, once the the Enter key is pressed (ie. inside the Context Search control). That may be enough to handle the situation the OP is finding unhelpful. ... It may also make MM5 perform better on slower PCs ... ie. don't jerk the screen around until you are sure that the user has completed entry of their filter criteria string.

I agree with this. Performance on MM5 is a consistent issue, and the search speed is okay at best even on my relatively powerful computer. Switching views always causes thrashing for me, so giving the option to only search once Enter is pressed is a very good idea. It can help with battery power as well.

The other thing that you may notice from his Video is that he had the Column Browser open, with an active filter criteria, when he (accidently) typed the contextual filter string. ... what happens in this situation is that the new contextual criteria replaces the active Column Browser, rather than being additive. ... ie. he was filtered to a specific artist (via Column Browser), and then he filtered more (via the Contextual Filter facility) ===> you bounced him out of the artist he was filtered to, and showed him tracks from any artists ... that will never be what the user is trying to achieve ... can it be fixed?

I believe that's what the option of switching to power scroll is supposed to be for. But it's not very useful, because it looks like power scroll only searches the first column that's being sorted. (That's what I was confused about in the video.) So if I'm sorting by Album Artists THEN Album THEN Song title, if I power scroll for a song title, it'll just say "X phrase was not found in Album Artist." I would expect it to first scroll to the corresponding album artist, then if it didn't find a matching AA it would search inside Albums, then if it didn't find a matching Album it would then scroll to the corresponding Title.

[Barry4679]

I believe that's what the option of switching to power scroll is supposed to be for. But it's not very useful, because it looks like power scroll only searches the first column that's being sorted. (That's what I was confused about in the video.) So if I'm sorting by Album Artists THEN Album THEN Song title, if I power scroll for a song title, it'll just say "X phrase was not found in Album Artist." I would expect it to first scroll to the corresponding album artist, then if it didn't find a matching AA it would search inside Albums, then if it didn't find a matching Album it would then scroll to the corresponding Title.

I think that the scroll_to feature has become broken, so it is hard to see what is going on atm, and this is causing much of your confusion.

IIRC I don't believe that the scroll feature works like you expected. I think that it scrolls using only from the current primary sort index.

After listening to your video a couple of times I am not sure that you have the full picture atm ... advance apologies if I cover things that you are already on top of, but maybe this will help?

Firstly, just to be sure that we have common ground. I don't see any custom collections in the video ... you understand how this works?

The other name for a top level node in the Media Tree is a "collection" ... MM5 ships with one standard collection, which is "Music". This collection is filtered to just show your music tracks ... ie. no podcast or non-music videos ... You can add your own custom filtered collections to the Media Tree .. eg "New Jazz I Am Trialling" may be filtered to just jazz tracks that you have ripped in the last 90 days, which you have played less than 3 times.

The Ctrl+F search facility, which is at the right of the toolbar is a global facility ... it searches the whole database ... it jumps away from whatever collection you are currently viewing, and starts a fresh new session, searching your whole database.

The "contextual search facility", which opens in the centre of the tool bar, when you type some characters while focus is in the centre panel, is just searching within the context of filtered results of whatever collection you have open. Is is not a fresh new session, it is just further filtering of the already filtered collection that you are viewing.

It comes in two flavours .... filter, and search (aka scroll-to).

• Filter will further focus the display, by reducing the tracks|albums by adding in the new filter criteria

• Scroll-to keeps the same quantity of tracks, but scrolls to the next match using the current primary sort column

In your video you also had the Column filter open. This means that you had three levels of filtering active:

1. the Collection ... you had Music open, so you were filtering to just music tracks
2. the Column Filter ... you were further filtering to just music tracks in the album named Aims by Vienna Ting (or something like that )
3. and then you typed something, which introduced a third level of filtering ... it should have filtered to just tracks from Aims, which has the character "2" as the 1st character of any "word", in any tag ... but it is broken IMO ... it jerked you away to another View, and started a fresh search session ... so it is no wonder that you didn't like that.

But thinking of the filtering power of MM5 (when it works properly) I think that it is a beautiful thing.
If they introduced the option to delay the application of the contextual filter|scroll, until the Enter key was pressed, you might like it better, and find it very useful, growing towards indispensable ?

[drakinite]

Probably. That does sound very nice, actually. And you're right, I actually didn't know that stuff about filtering within the context of the current view. I always just used the default Music collection, because I never felt the need to go beyond that.

[Ludek]

1) As for the new options to take no action when typing and to search only once Enter is pressed, added as https://www.ventismedia.com/mantis/view.php?id=17058

2) As for the fact that Music collection in List view cancels the current view when filtering (unlike Music > All tracks), added as https://www.ventismedia.com/mantis/view.php?id=17059

3) As for the fact that filtering has higher priority than 'Column Filter' when filtering. I guess this is all right.
Example:
- typing "moon" the Column Filter is filtered allowing you to see just the artists having tracks with "moon". e.g. artist 'Air' having "Moon Safari" album https://www.dropbox.com/s/es3amq5q02t7o ... 4.png?dl=0
- subsequently if you change "moon" to "moonlight" then artist "Air" is no longer an item in the Column FIlter: https://www.dropbox.com/s/k85ozg45t31t0 ... 4.png?dl=0

If it were like Barry suggested then the 'Column Filter' would have to become empty after changing "moon" to "moonlight" -- which would look like there are no items with "moonlight", but there actually are (as shown on my second screengrab)

4) There is a regression in 2273: Global search now shows only the track entities, no longer the album/artist/playlist entities (like shown on the previous drakinite's video)
To be fixed as https://www.ventismedia.com/mantis/view.php?id=17060

[Ludek]

4) OK, just my test error (not a regression). I had selected "Tracks" instead of "Browser" view: https://www.dropbox.com/s/qh5bjknsgyga4 ... 9.png?dl=0
On the same time I believe that "Tracks" should be renamed to "List" for consistency.
Fixed in 2274

[Barry4679]

3) As for the fact that filtering has higher priority than 'Column Filter' when filtering. I guess this is all right.
Example:
- typing "moon" the Column Filter is filtered allowing you to see just the artists having tracks with "moon". e.g. artist 'Air' having "Moon Safari" album https://www.dropbox.com/s/es3amq5q02t7o ... 4.png?dl=0
- subsequently if you change "moon" to "moonlight" then artist "Air" is no longer an item in the Column FIlter: https://www.dropbox.com/s/k85ozg45t31t0 ... 4.png?dl=0

If it were like Barry suggested then the 'Column Filter' would have to become empty after changing "moon" to "moonlight" -- which would look like there are no items with "moonlight", but there actually are (as shown on my second screengrab)

Good discussion. Thanks.

Typically I agree with most of your judgements, but here my opinion is the opposite. ... Maybe we are talking about different things, and there is confusion?

Firstly I don't seem to see what you see. I now have 2273. Here I had an active column filter to artist Air, then I typed moon as a contextual search ===> it trashed my context, closed the Column Filter panel, and gave me a display of any "moon" track within the collection ... I would never expect, or want that .... If I did, I would toggle the Column Filter off before typing moon, or change the Artist to "All" in the Column Filter ... both of which are easy to do, and easy to understand

I can't understand why you would think that the current behaviour is desirable?

You provide a contextual search feature, but then don't define the "context" as being what I am currently looking at? .... how is that good? ... I am looking at something ... want to refine it, and you push me back where I was some time ago, before enacting my request.

And you are not consistent ... if I achieve the same filter of artist = Air, but this time using the Advanced Filter ==> you do the opposite thing ... ie. you see Air's tracks as being the context ... which is good, and expected.

I can't see why you treat these two situations differently. ... When you switched from 'moon" to "moonlight" ... it was obvious that one replaces the other, as one is overwriting the other in the same control. ... but how is it obvious that user is exiting their Column Filter context when they type "moon" into the main panel?

We are back where this thread started ... MM5 design imposing some expected and unwanted jerk away from the users' current view and context.

If it were like Barry suggested then the 'Column Filter' would have to become empty after changing "moon" to "moonlight" -- which would look like there are no items with "moonlight", but there actually are (as shown on my second screengrab)

No. I would expect that a new, or altered, contextual filter would trigger no change to the Column Filter ... it would be additive to whatever was was my context, as defined as the sum of:

• the Collection's criteria

• and the Advanced Filters criteria

• and the Column Filter's criteria

Maybe there is a misunderstanding?
Or maybe it is difficult to program or retro-fit? ... maybe ... but from my POV it is what is logical, expected and useful. ... Probably like you, I don't have too many tracks by Air, but situation is vey different if I have used the Column Filter to filter to a Genre, or somewhere else where there are many rows. This is where MM5 filter could rock (more ).

We are

[Ludek]

Firstly I don't seem to see what you see. I now have 2273. Here I had an active column filter to artist Air, then I typed moon as a contextual search ===> it trashed my context, closed the Column Filter panel, and gave me a display of any "moon" track within the collection

This is because of the issue https://www.ventismedia.com/mantis/view.php?id=17059
i.e. you tested Collection in List view, but I tested Collection > All tracks in List view
Once the #17059 is fixed then you will see the same also in Colelction List view

Otherwise the current filtering sequence (based on preference) is
Collection criteria -> funnel filter -> contextual search -> Column filter

So the Column filter is the last in the sequence (the least preference) and shows the results of the search components above. Maybe you are suggesting that Column Filter should have a higher precedence and shouldn't be filtered -- i.e. just the tracklist should be filtered and the Column Filter would just show all values in all columns unfiltered by contextual search?? i.e. the sequence would be Collection criteria -> funnel filter -> Column filter -> contextual search
Hard to say what is preferable/desired, I like that currently the contextual search has a preference as this way I can see the columns filtered, i.e. showing all artists having tracks with "moon", showing all genres having tracks with "moon" and I can easily click the "Moon safari" album of artist "Air" if I am looking for it.

[Barry4679]

This is because of the issue https://www.ventismedia.com/mantis/view.php?id=17059
i.e. you tested Collection in List view, but I tested Collection > All tracks in List view
Once the #17059 is fixed then you will see the same also in Colelction List view

OK, thanks.

Now that I see the intended behaviour, I see that there are arguments both way.

Hard to say what is preferable/desired, I like that currently the contextual search has a preference as this way I can see the columns filtered, i.e. showing all artists having tracks with "moon", showing all genres having tracks with "moon" and I can easily click the "Moon safari" album of artist "Air" if I am looking for it.

A good point; a use case that I hadn't considered.

the current filtering sequence (based on preference) is
Collection criteria -> funnel filter -> contextual search -> Column filter

I still prefer preference for Collection criteria -> funnel filter -> Column filter -> contextual search, but do admit that it is less black & white due to the above.

For your consideration, my reasons are:

1. Power: The Column Browser is more powerful ... it is multi-dimensional, and we can easily introduce new dimensions, or reconfigure precedence via drag & drop ... there is nothing else that powerful in MM ... it is like the Media Tree on steroids ... it is just as good as at navigating, as it is for filtering ... the contextual search feels relatively puny by comparison ... it seems logical (to me) that the best tool for heavy lifting should be at a higher level of precedence, when you are doing the many to the few filtering .. and that Contextual Search is best for refining things with a tweak, once the 1st cut Navigation|Filtering is done
2. Fixture: The Column Filter is persistent feature ... ie. the Manage View facility allows us to customise Views that it will visible by default ... I will be doing that. I always had it open in MM4 ... alternatively if you just have the Column Browser temporarily visible, and then switch to a different collection, and then return ==> the Column Browser is still visible ... this is not the case for the Contextual Search box ... These two things make the Column Browser feel like a more senior actor in the filtering space
3. Intuitive: The Column Filter behaviour is a well known carry over from MM4, making it feel like a 1st order facility ... The Contextual box is a MM5 innovation, and from a MM4-experience perspective it feels like a refinement to MM4 1st order facilities ... subjective I know

OTOH the one argument that I see for the current approach is:

1. Targeted. The Contextual Search facility is, by default, a shot gun approach. ... ie searches all tags, and file attributes, for any match ... by comparison the Column Browser is targeted. For some Use Cases this makes the Context Filter an OK candidate for the senior role ... Marginal in my case because I am album focused, and I know my collection very well.

Maybe you are suggesting that Column Filter should have a higher precedence and shouldn't be filtered -- i.e. just the tracklist should be filtered and the Column Filter would just show all values in all columns unfiltered by contextual search??

No, I am not suggesting that.

We are obviously coming at this from different POY. ... Your initial intention was to deliver MM5 without a column browser, as you felt that had been superseded by the new facilities. This obviously fits your Use Case .... My POV is that MM5 without the Column Filter is unthinkable. ... As you say, both precedence choices are debatable.