Add "Open in Explorer" for playlists

[Borewit]

Resolves #56

• Adds Open in explorer main menu to open playlist folder
• Adds Open in explorer playlist tree meu
• Adds Open in explorer to open playlist entry (audio track) folder

[Borewit]

Build listFix_2.5.1-[PR61]-9.
Note: ToDo: Adds Open in explorer to open playlist entry (audio track) folder

[Borewit]

Build: listFix_2.5.1-[PR61]-10.exe

[touwys]

You are really moving along so fast, it's hard to catch up with you. 😳

Again, I need to know whether you want me to install and test the builds in the order which you release them? Sometimes I am not ready to test the first build before the release of newer builds. A case in point, for example, given below in order of the listFix() current releases:

1. Build: listFix_2.5.1-[PR47]-25
2. Build: listFix_2.5.1-[PR61]-9
3. Build: listFix_2.5.1-[PR61]-10

Do we jump straight to 3? I think we should establish some kind of release protocol for this, do you agree, or maybe such already exists one already for situations similar to this?

[touwys]

It's really fantastic to read that you have already added the "Open in Explorer" enhancement. 👍 Thank you! Hopefully, the current build can be tested today. Looking forward to it, very much.

[Borewit]

think we should establish some kind of release protocol for this

Created Release Procedure in PR #62.

[touwys]

listFix_2.5.1-[PR61]-10

1. This build was installed straight away, skipping the other two.

2. The Playlist and Media Directories were added, anew.

3. Changed these programme options: font size and style, theme, and the number of closest matches to return when searches for.

4. Selected 12 contiguous playlists from the playlist directory.

5. Opened all 12 playlists in the "Playlist Editor".

—— 5.1 In order to standardise, shall we consider to rather call the playlist repair pane the "Playlist Editor" from now on — or do you perhaps want to standardise on something else? In fact, I think this pane should get a title at the top? What do you think? Clear and precise naming is important for so many usage and support reasons.

—— 5.2 The tab-titles of the all 12 playlists, now open in the "Playlist Editor", were corrupted as before — exhibiting what appears to be superimposed labels/text.

—— 5.3 Each of the labels now displays the tab-closer "x" visibly, where it should. Clicking the "x", closes the tab properly.

—— 5.4 A right mouse click, activates the tab, but nothing else happens. Is this action not supposed to evoke the tab context menu, which controls certain operations to be performed on it, such as: close the tab, close all tabs, close other tabs, and more?

—— 5.5 The command to close all tabs, were only possible to execute from the File menu, as well as the keyboard shortcut CTRL+Shift+W.

—— 5.6 After closing them all (5.5), one playlist remained behind in the "Playlist Editor" — but without its tab — and this playlist was impossible to close by any of the usual means. It only cleared after restarting the app._

6. Next, tested one broken track found in a playlist. The closest match for it was quickly located, and displayed in the "Select Closest Matches" dialogue. The Preview>Play action worked as it should. However—

—— 6.1 Clicking the "OK" button did not fix the broken track in the playlist.

The test ended at step 6. Awaiting response.

•
Playlist Editor Status (19)
•
Playlist Editor Status (53)
•

[Borewit]

In order to standardize, shall we consider to rather call the playlist repair pane the "Playlist Editor" from now on

Sounds good, please capture that in a new issue.

The tab-titles of the all 12 playlists, now open in the "Playlist Editor", were corrupted as before — exhibiting what appears to be superimposed labels/text

Update of issue #55. As this PR is a small change, you can assume that problem is now present on the default branch.

@touwys, it important to try to capture every unique problem or suggestion for improvement in 1 issue as much as possible. That way I can follow up with a fix (PR) for that specific problem. Test results of that specific fix (PR) should be report back into the corresponding PR. If you find new problems, please create new issues. You can refer back in that new issue to specific build, even it was part of PR, no problem. That way a systematic log and approach to address things we want improve will grow. That way we have a clear overview what is still to be done, and what is been solved / implemented.

[Borewit]

If it works better for you write things down in 1 combined report, like the regression test results you posted here, you can also open a new issue for that, and we create and link smaller issues from there.

I can make a build for the current default branch if you like, then you know for sure everything you find is a new issue unless we have an existing open issue.

Update: Created issue: #64 to capture regression testing.

[touwys]

If it works better for you write things down in 1 combined report, like the regression test results you posted here, you can also open a new issue for that, and we create and link smaller issues from there.

@Borewit: My sincere apologies for making a mess of it. Ascribe it to my cluelessness, which is not going to improve any time soon. Therefore, I prefer to stick to what I understand, like writing a single report, and just leave the dissemination of that input up to you to sort out, whichever way you deem fit. You'd be the best judge for that. If you see anything out of place, please do move it to the appropriate location.

Thank you for your understanding.

[touwys]

@Borewit

Herewith a new screenshot of the Playlist Editor, in addition to the two screenshots which were provided yesterday:

•
Playlist Editor Status 19(2)
•

—— 5.6 After closing them all (5.5), one playlist remained behind in the "Playlist Editor" — but without its tab — and this playlist was impossible to close by any of the usual means. It only cleared after restarting the app._

This particular issue also disappeared under the circumstances explained in the aforesaid screenshot.

[Borewit]

Part of release v2.6.0