Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smarties (or SmartList or SmartCrate or QueryCrate or QueryList or ...) open for feedback. #14182

Draft
wants to merge 47 commits into
base: main
Choose a base branch
from

Conversation

Eve00000
Copy link
Contributor

Smarties

  • save lineditsearch to new smarties

some remarks:

  • I read #5575 carefully and tried to follow some ideas from that conversation.

  • smarties are crates with other capabilities : No autoDJcrate, no adding tracks, no export (make crate of the smarties)...

  • smarties can be 'live' and 'cached' : when the smarties are locked they are cached, else the search is executed when selected (but this goes fast, I'm testing with 13000 tracks table in Virtual Machine, it's just a wink). Cached = tracks in smarties_tracks
    -> when title / name of track is changed and the track is no longer conform with the condition the track continues to stay in the smarties until the smarties is unlocked.

  • in querysearch ienter your seartch, push the white square and your search becomes a a smarties.

  • click with right mousebutton on a smarties -> edit -> 12 conditions, all track fields with an operator and an value-input
    -> Smarties are SMART
    all meaningful fields of the library can be selected, with matching operators.

  • it's possible to use a crate / playlist or historylist in a condition (dropdown)

  • each condition needs to end with AND / OR vombined with ( )

  • the last condition needs to end with ) END.

  • conditions can be switched moved up / down / inserted / deleted. only 12 conditions possible.

  • with apply the query is shown as it would be executed

  • before are smarties query is saved it's checked -> green rectanhle ok, red = problem

  • smarties are updated while updating the conditions -> apply

  • I added the 'grouped' logic as in 'grouped crates"

please test and send me feedback

NOTE: there are still a lot of 'leftovers' from conversion of crates to smarties, things that might be used in the future (I'm still in dubio).

20241026.Eve.Mixxx.Smarties.mp4

392702775-ec8dab70-5e24-422e-8714-320ee5b99534

392702783-27403eab-7f78-4a7f-9330-5dd3719c77b5

392702789-f84c288e-2d5c-444c-8ddb-d3a25cf2a8bf

392702796-ad075354-c821-4f3e-a87e-ede317fe2b8d

392702798-9e36c2b4-3784-4f20-8d93-b2538541b1be

392702802-ce0e5031-a990-4a2b-81d7-5d7951db22fc

20241026.Eve.Mixxx.Smarties.mp4

afbeelding

afbeelding

afbeelding

afbeelding

@ronso0
Copy link
Member

ronso0 commented Jan 20, 2025

Wanted to do a quick test, but ran into this assert.
When I clicked the smarties button the query was
bpm:=123-130 title:gras
assertion:
DEBUG ASSERT: "!Condition4Field.isEmpty()" in function void DbNamedEntity<T>::setCondition4Field(QString) [with T = SmartiesId] at ./src/util/db/dbnamedentity.h:205

@ronso0
Copy link
Member

ronso0 commented Jan 20, 2025

I'll mark this draft for now since there's a lot of unrelated and unused/commented stuff in here.

@ronso0 ronso0 marked this pull request as draft January 20, 2025 09:58
@Eve00000
Copy link
Contributor Author

Wanted to do a quick test, but ran into this assert. When I clicked the smarties button the query was bpm:=123-130 title:gras assertion: DEBUG ASSERT: "!Condition4Field.isEmpty()" in function void DbNamedEntity<T>::setCondition4Field(QString) [with T = SmartiesId] at ./src/util/db/dbnamedentity.h:205

thank you
bpm:=123-130 title:gras
I'll need to remove the = (equal sign)
did you try other searches?

@ronso0
Copy link
Member

ronso0 commented Jan 20, 2025

Just my 2 ct wrt the implmentation:
first of all, thanks for starting this!
Though, for such huge projects / feature it's often if not always better to discuss and design together before investing countless hours in the implementation. Because, thing is if the design is not adequate / has significant flaws (UX or techincal) a lot of time has been 'wasted' (not literally because contributors got to know the codebase better, but the effort / usable outcome ratio is very low), and for salvaging some of the code / fix the design, reviewers have to invest a lot of time and contributors usually get frustrated, and likely the entire feature stalls. This has happened often to Mixxx PRs, so please let's avoid that in the future (or expect a PR to rot due to missing reviews).

@Eve00000
Copy link
Contributor Author

Eve00000 commented Jan 20, 2025

Thank you, indeed the goal was double:

  • getting more acquainted with the code and sharpen my c++ knowledge
  • having the feature myself as I was missing it (as I mentioned in different posts)
    So certainly no time is waisted, I already enjoy the feature.

Concerning the discussion... As some discussions go on eternally without having a clear (and steady) outcome and as some discussions are more about the coding itself than about the logic or the feature, I label those as a real waist of precious time which I could have invested in the features I'm really missing. So I'm avoiding them.
I don't want to offend anyone, this isn't negative critisism, just a conclusion.
So I create, share and offer, if there is no interest ... so be it, if there is ... I am happy to work together with others to adapt it and get it better / to get it fit in the codebase. I think you (and some others) have quiet the same philosophy.
The time possible reviewers have to investigate in reviewing the code can't be compared with the time I investigated to learn the complete codebase (as I wrote before about missing descriptions / analyses). "You'll learn reading the code"

If my pr's rot or get stalled ... all who wants the feature (and especially I) can have it.
It's almost a year since my rediscovery of Mixxx and my 'getting involved', I like Mixxx a lot, I'm very happy with my rediscovery, with the evolution of Mixxx, with the lovely people I learned to know. But there are still some things missing IMO, so instead of waiting for them, I'm creating them myself and I am happy to return to the community as much as I can, I wont stop contributing and my involvement / commitment will only grow as my Mixxx-knowledge grows as wel, but my first love is (playing) music, not coding and that won't change. I don't have the ambition to reach the same level as other Master-coders (I wrote it with a capital) for whom I have much respect.

I wrote this spontaneously (as in my nature) and didn't think over my words and thoughts, If I offended someone, please accept my most sincere apologies, I didn't mean to.

Addendum: maybe the "Blue Monday combined with today's halloween-pumpkin event"-effect caused me to write my reflections.

@ronso0
Copy link
Member

ronso0 commented Jan 22, 2025

Wanted to do a quick test, but ran into this assert. When I clicked the smarties button the query was bpm:=123-130 title:gras assertion: DEBUG ASSERT: "!Condition4Field.isEmpty()" in function void DbNamedEntity<T>::setCondition4Field(QString) [with T = SmartiesId] at ./src/util/db/dbnamedentity.h:205

I still had a binary of this branch in my build dir and when I attempted to run it (to quickly check something unrelated) I ran into the same debug assert again, even before the main window showed up.
So there's definitely something that needs to be fixed here.

@Eve00000
Copy link
Contributor Author

thank you, I wil check it out profoundly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants