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

add History cleanup options #4726

Merged
merged 10 commits into from May 9, 2022
Merged

Conversation

ronso0
Copy link
Member

@ronso0 ronso0 commented Apr 15, 2022

After the History rework #2996 I'm finally adding some options to Preferences > Library for configuring how the history playlists are cleaned up.

  • configure tracks threshold for histories to keep
  • allow to keep locked playlists with fewer tracks
  • always keep locked playlists
  • allow adjusting the "recently played" threshold (tracks that are NOT added twice to the history) lp:1766163
  • reset "recently played" list when starting a new session manually ("Finish current and start new") lp:1969217
  • reorder / re-group the library options in the GUI

image

@ronso0 ronso0 marked this pull request as ready for review April 16, 2022 09:15
@ronso0
Copy link
Member Author

ronso0 commented Apr 16, 2022

I'm done here. Options work as expected, GUI looks good.
Any hints regarding the wording in the preferences are welcome, especially from native speakers @Be-ing @ywwg

@ronso0 ronso0 added this to the 2.4.0 milestone Apr 17, 2022
@foss-
Copy link
Contributor

foss- commented Apr 19, 2022

Very useful changes that improve usability a lot. Is allowing to select more than a single entry, analogue to how multiple files are selected in file manager, in order to bulk delete history entries, out of scope for this PR?

ronso0, you already commented on https://bugs.launchpad.net/mixxx/+bug/1968503 which should also be updated once this is merged. In your screenshot the UI looks misaligned when looking at the text rows and the setting to the right.

@ronso0
Copy link
Member Author

ronso0 commented Apr 19, 2022

Is allowing to select more than a single entry, analogue to how multiple files are selected in file manager, in order to bulk delete history entries, out of scope for this PR?

yes, I'm not going to work on that now.
This PR only adds the interface for existing functionality and fixes bugs.

@ronso0
Copy link
Member Author

ronso0 commented Apr 19, 2022

In your screenshot the UI looks misaligned when looking at the text rows and the setting to the right.

That is already fixed, the note is now in the tooltips of the spinbox and the checkbox. I updated the screenshot.

@foss-
Copy link
Contributor

foss- commented Apr 19, 2022

Is the fields width expected? This will likely not be more than two digits, thus it looks a bit too wide for its purpose.

@ronso0
Copy link
Member Author

ronso0 commented Apr 19, 2022

Sure, but if the translation string is rather short there will be a lot of whitespace in between the labels on the left and the spinboxes. Keeping them closer together improves readability, like avoiding long lines in continuous text to ease finding the beginning of the next line. That's also the reason why the row height and search timeout labels are right-aligned.

@ronso0
Copy link
Member Author

ronso0 commented Apr 19, 2022

select more than a single entry, analogue to how multiple files are selected in file manager, in order to bulk delete history entrie

FWIW I'd not do this from in the sidebar. We'd need to switch from single- to multi-selection and I think it's tricky to get the UX right.
I'd prefer the simpler approach of adding a seperate dialog for this, for example a listw view with checkable items, probably grouped by year and month.

@daschuer
Copy link
Member

Is there a need for the checkbox to delete locked lists? I would prefer to dispose it and never delete locked playlists.

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks and works good. Only the naming can be improved. Thank you.

const ConfigKey mixxx::library::prefs::kHistoryRecentlyPlayedThresholdConfigKey =
ConfigKey{
mixxx::library::prefs::kConfigGroup,
QStringLiteral("history_recently_played_threshold")};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is hard to understand. It is the number of tracks that has to be tracked, before a track is re-entered.
It has been introduced to not list a track many times when scratching.
Maybe "history_reenter_distance" .. "history_rerecord_inhibit_gap" or something better.
The same applies to the GUI.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

history_track_readd_threshold?
If you don't consider that suitable either I'd rather add a comment here than creating a foot-long configkey.

In the preferences the spinbox tooltip explains the meaning. Do you think that's not sufficient?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about
'Recently played' threshold to prevent duplicate entries
?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"history_track_readd_threshold" works better for me, while "threshold" can be anything. That's why I had proposed "gap" or "distance"

'Recently played' threshold to prevent duplicate entries

This can be improved because it will not "prevent duplicates" it just sets the minimal distance of duplicates.

"Track re-add threshold" works also in the GUI

but how about:
"Minimum distance of repeated tracks"?

and for the config key

"history_track_repeat_distance"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"history_duplicate_distance"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I wasn't really in the shape to come up with a proper term.
I'll go with history_track_duplicate_distance and for the History preference "Track duplicate distance"

const ConfigKey mixxx::library::prefs::kHistoryCleanupMinTracksConfigKey =
ConfigKey{
mixxx::library::prefs::kConfigGroup,
QStringLiteral("history_cleanup_min_tracks")};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this the max length that is cleaned up?
how about something like: "max_tracks_auto_delete"
Or the other way around "min_entries_to_keep"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, it's the "minimum tracks count to keep playlist":

"SELECT id FROM Playlists  "
"WHERE (SELECT count(playlist_id) FROM PlaylistTracks WHERE "
"Playlists.ID = PlaylistTracks.playlist_id) < :length AND "
"Playlists.hidden = :hidden AND Playlists.locked = :locked"

https://github.com/mixxxdj/mixxx/pull/4726/files#diff-4112e31df339e252ee2f3f49b18e1daf2ce58aaf488f5f4db43ab98c4aa83ff7

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, for me this combination is sensible "min + keep" or "max + cleanup/delete" is correct.
"min + clenaup" feels wrong, while cleanup is not well defined.

From your explanation we may use "history_min_tracks_to_keep" or such.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, I changed it.
The preferences UI is okay IMO
image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be possible to substitute the N with the number widget inline?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you fear the N / X / ? placeholder will not be understood?

Puuting the actual number in the label would work but I don't see the benefit of this redundancy tbh.
Inline spinbox is also possible but its position depends on the translation, and it screws up the layout. Sooo: tricky..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhmm makes sense. I just thought it would result in better UX, but considering the challenges it causes, I agree that its not worth the effort.

@ronso0
Copy link
Member Author

ronso0 commented Apr 20, 2022

Is there a need for the checkbox to delete locked lists? I would prefer to dispose it and never delete locked playlists.

Good point 👍 I'll remove it.

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you.

@daschuer daschuer merged commit 30cc5f1 into mixxxdj:main May 9, 2022
@ronso0 ronso0 deleted the history-cleanup-options branch May 12, 2022 21:11
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.

None yet

4 participants