Search Push Pin

[TristanYoung]

Feature Description

I make extensive use of CRATES to sort my music.

I also do a lot of searching for specific track names, and sometimes want those searches to carry across the different CRATES.

It would be nice if Mixxx offered a push pin for the search facility, so my last search remains persistent as I select different crates.
I'd also like to see the status of the push pin saved, so that the next time I run Mixxx, the push pin will automatically be enabled or disabled based on last use.

Thank you.

[daschuer]

This puzzles me as well.
Especially when I search a crate, realize the track is not there and than I like to search all tracks. I find my self often retyping the same query.

Keeping the query unconditionally by such a global "push pin" stands against the stateful model, where you have filtered a view for specific needs like a bpm range, than search a track in all tracks and go back to the filtered view.

How can we support both use cases without messing up one or the other? Do you have ideas?

Related:
#7470
#5575

[TristanYoung]

Hmmm.

While trying to understand your reply, I may have found a bug. I'll address that last.

If you are referring to each part of the library remembering its own search parameter, then I would have the pushpin act as an override that works across the different sections/folders (Tracks, Playlists, Crates, Auto DJ, Analyze). It wouldn't be altering the stored per section search query. When the pushpin is released, the override is disabled and the stored per section search query is used. That would respect the custom filtered view per section. The only problem is the search we were trying to perform wouldn't be retained.

Which brings up the idea of a search history, which I believe someone has brought up before.

Now the possible bug - folder search queries aren't remembered.

If I enter a search query in Crate #1, and then switch to Crate #2, and then back to Crate #1, the search query for Crate #1 is gone. Same thing happens if I substitute Crate #2 with Tracks - the tracks section remembers its last-used search query, but when I return to Crate #1, the search query is gone. Same thing happens with Playlist folders.

Is this the desired behaviour?

I might bounce back and fourth between a Forest Psy crate and Dark Psy crate, and I want a custom search view showing tracks that fit a certain BPM range, but not necessarily for other crates such as Psy-Ambient.

[poelzi]

Each feature can device which values go into the key and therefore if the history contains some subpage or not. This can be easily changed.
The search query is only saved after some timeout to not spam the history. It makes sense to save the entry when a switch happens. @TristanYoung Do you switch fast ?

[poelzi]

I would implement it like this:
If pin in pressed, and a longer timeout occures, in the best case, the query yields actuall results, the entry is also added to the history of the subpage. Changing the search entry, despite pin set, will always add it to the current search query.
Releasing the pin will always add the searchquery that was pined to the current history.
Pinning a search query will always add the search query to the place the pin was triggered.

[daschuer]

Thank you @poelzi that sounds great.

Does this mean:
Switch feature with search pinned:

• Search box content is kept
  Switch feature with un-pinned:
• Search box is replaced by the last search entry in the history
  Unpin Search before editing the pinned value
• discard pinned search and show last search entry in the history
  Pin Search before editing the history value
• Past the search entry of the previous selected feature as if the pin has been pinned.

[poelzi]

This was an hypothetical would, I don't see any time in my near future

[daschuer]

@TristanYoung The side-issue you have discovered has been already fixed in 2.4-alpha.

[ronso0]

If pin in pressed, and a longer timeout occures, in the best case, the query yields actuall results, the entry is also added to the history of the subpage. Changing the search entry, despite pin set, will always add it to the current search query.
Releasing the pin will always add the searchquery that was pined to the current history.
Pinning a search query will always add the search query to the place the pin was triggered.

Sounds like search history per feature? I think this will get very confusing if you switch features often.

FYI a pinned search can probably easily be added now that #11129 was merged.

Side note:
While there are a few valuable searchbar improvements, I wonder if if there's a way to squeeze more action buttons into the searchbar (and drop-down list) while it's next to the tracks table, and thus usability always depends on the sidebar/tracks split size. Maybe it should finally be moved to above the tracks table, regardless if the table shows 1-2 items less then.

And (while I think the push pin feature is one of those) I wonder how much work we want to put into tweaking the xml/QWidget-based library GUI until QML is mature -- or maybe features can easily be ported to QML once they are settled UX-wise in the legacy skin system, idk

[ronso0]

Which brings up the idea of a search history

Thanks to @poelzi that is already implemented in Mixxx 2.4-alpha : )