Double printed tab pane headings of the playlist editors

[Borewit]

I cannot reproduce the issue, opened a large number of playlists, and closed all of those, and then opened then again, repeated that a few times, no side-effects:

We're missing something here. It seems like this issue is due to one or other file corruption. It does work properly with a clean installation, and that *.ini file removed. What causes this issue is yet to be established. It seems to be something that was introduced in later builds.

Just now, I deleted all the json settings files, restarted the app and set it up all over again. Then reopened the 12 playlists for repair, and yet their titles were still contaminated. It looks like two superimposed titles, as I explained before.

What happened next, is surprising, I opened the Options dialogue, and tried to change the number of closest matches to find. The app immediately started to hang... I moved the indicator around... video:

Animation demonstrating the issue

Originally posted by @touwys in #51 (comment)

[Borewit]

@touwys Looking to the animation it looks like the "GUI-threads" hangs, essentially making you application unresponsive and the rendering (painting) to fail.

[touwys]

@touwys Looking to the animation it looks like the "GUI-threads" hangs, essentially making you application unresponsive and the rendering (painting) to fail.

What do I look for, and what can be done about it? Can the graphics card be to blame for it, e.g. driver? Both were recently installed.

[Borewit]

What do I look for, and what can be done about it? Can the graphics card be to blame for it, e.g. driver? Both were recently installed.

Good question. Maybe you cannot do much about it at this moment. By keep improving (refactoring) the code, I hope we slowly shake out issues. There are still area's many area's where I can improve logging and exception handling.

I need to focus on some other things now for a few days. But when I have time I will also play around see if I can trigger problems. I can also deploy it do another Windows PC, see if that makes a difference.

I am also adding unit tests, they test smaller software components, like loading / saving playlists.

The great thing about unit tests are, they can be checked automatically. An each commit I push to a PR, those are run and the PR will turn red if something fails. What makes it tough for this application write unit test, is that the all the file path are OS specific.

[touwys]

Good question. Maybe you cannot do much about it at this moment. By keep improving (refactoring) the code, I hope we slowly shake out issues. There are still area's many area's where I can improve logging and exception handling.

Good, so far the graphics card is working properly, with zero issues manifesting. Installed it 7 days ago.

I need to focus on some other things now for a few days.

No rush, I need a break too 😂

I am also adding unit tests, they test smaller software components, like loading / saving playlists.

It looks like these unit tests are going to be a huge productivity boon for weeding out any issues. Are the test units to be run under a single controlling app?

[Borewit]

Are the test units to be run under a single controlling app

Multiple ways to execute the unit tests.

In principle is done via Gradle, running ./gradlew : test

Which can be executed by my IDE (development environment):

It's done as part of the Pull-Requests (PRs), just added some better visual feedback: https://github.com/Borewit/listFix/actions/runs/4097667916/jobs/7066209974

So basically nothing is able to be merged to the default branch without passing unit testing.

[Borewit]

@vall77 now you got listFix running on Linux, can you try to reproduce this issue?

[Borewit]

Is this intended for me?

No, was addressed to @val77. As he has totally different environment, I can shed a different light on this issue.
There is also a risk he finds issue we do not experience, as the path handling is different on Unix.
I have done 0 testing on Unix with the last versions.

[touwys]

@Borewit

Any feedback on this test within the Linux environment, yet?

In build listFix_2.5.1-18 , the issue (of the overlaid tab-text) persists.

[Borewit]

Issue still persist in listFix_2.5.1-19, reported here

Any feedback on this test within the Linux environment, yet?

Not yet

[touwys]

Issue persists in build: listFix_2.5.1-25

[Borewit]

I cannot neither reproduce this issue under Linux:

[Borewit]

We know now for sure that the double printed tab pane headings experienced by @touwys is related to:

listFix/src/main/java/listfix/swing/JDocumentTabbedPane.java

Line 118 in 4feac3b

this.setTabComponentAt(index, tabComponent);

as tested in PR #94 (comment).