GUI progress elements don't update on recent macOSes (and suggested fix)

[AEgbert]

At some point, I think a macOS update broke the way some of the progress indicators in the GUI are drawn. (I'm pretty sure it's been a few years at least, and I don't remember when they were last working correctly.)

Specifically, I've mostly noticed these issues:

• The "Processing: " label never updates to show the file being processed
• The progress indicator in the bottom right will only update the progress when the window becomes active/inactive (and then resets to zero after a moment)

I finally got around to cloning the code and seeing if I could track down the issue (not an expert here, so my explanation may be lacking). The main culprit seems to be using the GUI API outside of the main thread (which seems to not be a recommended practice--thread safety issues?). My guess is Apple added protections to the API calls at some point that breaks the functionality when called out of the main thread.

From the brief looking and testing I've done, it looks like you can fix this by dispatching the API calls to the main thread like this (example in progressUpdate):

// Replace this:
// [self.progressIndicator setDoubleValue:[f doubleValue]];
// with this:
dispatch_async(dispatch_get_main_queue(), ^{
        [self.progressIndicator setDoubleValue:[f doubleValue]];
   });

This style of wrapper should be applied to any UI API calls out of the main thread (i.e., in the thread running processNextFileInQueue).

Finally, I think the reason the progress bar periodically reset is because it's set to 0 in every call to updateView (runs every second by timerFire). Moving that set-to-zero call to somewhere else (processedFiles? End of processNextFileInQueue?) might be better.

I'm thinking about finishing up the modifications I made while testing and open a pull request addressing this issue--if there's interest, let me know and I'll try to get it together sooner rather than later.

P.S., Thanks so much for this project. I've been using it for years to check the volume levels on a podcast I edit, and (aside from these very minor issues) it's been perfect for me.

[audionuma]

Hello, unfortunately, for nearly two years, I have no more access to an Apple computer. I am not able to maintain the code anymore. For the time being, you would have to either fork the project and implement the fix or submit a pull request that I could pull on the repository without being able to test it. On the longer term, I wonder if there's something like transferring the owning of a repository and if someone would be interested. Would it have any advantage over a fork ? Anyway, I'm glad that this software has been useful to you.

[ShikiSuen]

@audionuma Is it okay to add me to the maintainers of this repository? I just rewrote the GUI version of r128x using SwiftUI (requiring at least macOS 12).

[ShikiSuen]

@AEgbert The entire current r128x-GUI target is deprecated. SwiftUI saved a lot of things. :) See my PR: https://github.com/audionuma/r128x/pull/12 .