Drop the "Exact Matches Repair...."

[Borewit]

Changes:

1. Drop the "Exact Matches Repair...."
2. Some minor code style improvements

Resolves #154

[Borewit]

Build listFix_2.7.0-PR157-2.exe

[touwys]

Build listFix_2.7.0-PR157-2.exe

Looks like bike-mechanic and software developer go hand in hand? 😄 I will grab this build tomorrow.

[Borewit]

Looks like bike-mechanic and software developer go hand in hand? 😄 I will grab this build tomorrow.

Flat tire, glue should be dry by now. Sure, enjoy your evening!

[touwys]

Review: listFix_2.7.0-PR157-2

1. Repair > Find Exact Matches is gone. (Should I have expected a change in the description of the two remaining menu items, in this build?)

2. Updating the Media Library with this took much longer than with listFix_2.7.0, and the previous build listFix_2.7.0-PR156-1

❓ Does it make sense to remove Find Exact Matches from the Repair menu, while keeping it as a tool in the Playlist Editor? Should we not then consider removing, too, the Find Exact Matches command (the binocular icon) from the Playlist Editor, since it is already inherent in the Fix Everything command (the magic wand icon)? Additionally, consider whether Fix Everything is an apt description for the command? "Find Closest Matches" is probably the more apt description for it.

[Borewit]

I also thing the "Find Exact Matches" does not make much sense. It does fix / replaces alternative broken entries with "exact" matched found.

What about this?
Fix everything => Find closest matches
Find Exact Matches => Repair playlist

Updating the Media Library with this took much longer than with listFix_2.7.0, and the previous build listFix_2.7.0-PR156-1

I don't think I have made any changes in the code which explain the difference in performance. After running a Java application for a while, it may become faster, as the just-in-time (JIT) compiler kicks in. Parts of the code run frequently are optimized, which first causing some delay and next time it runs faster. Other effects on negative performance may be caused by anti-virus software, and thing running in the background like Windows updates.

[Borewit]

Shall we merge this one and release @touwys?

Or do some renaming first as part of this PR?

[touwys]

Shall we merge this one and release

In my opinion, merge and release. Drop all other forms of searching, or any of the renaming for it. Retain only "Select Closest Matches", as this is really all, and the only action, that really counts — it's the sole reason listFix() exists. "Select Closest Matches" is already extensive in function, and now nearly complete, and with a dialogue full of usable features to find the best matches. Later, the last piece to fit the accurate search puzzle, the search algorithm, can be reviewed.

See also #154

[Borewit]

Thank you @touwys for providing a clear focus. Okay, I will strip out the "exact match" everywhere.

[Borewit]

Stripped out exact repair.
Renamed find closest match to repair playlist.
Build listFix-windows-exe

[touwys]

Renamed find closest match to repair playlist.

Looking good.

Off-topic: consider if a command to cancel the Menu > Repair > Repair all open playlists process, constitutes a productive addition? If you agree, I will add to the current crop over at issues.

[touwys]

Error found: when the app shortcut is pinned to the Windows Taskbar, it will display a blank icon, instead of the usual listFix logo-icon.