I made a juce app that gets command line arguments and runs some time-consuming calculation that takes a while to complete.
During this time the Activity Monitor is listing my process as “(Not Responding)”, while it’s actually working perfectly fine.
I believe this is due to JUCEApplication::initialiseApp calling juce_initialiseMacMainMenu (I think macOS doesn’t list command line apps as not responding and probably distinguishes by this main-menu initialisation).
I wonder what’s the best route to take. Shall I override initialiseApp?
I think the trigger for macOS to show “not responding” is, if there are messages from the OS stuck in the MessageManager longer than a certain timeout.
A solution for that problem would be, to add the chance for the MessageManager to process the OS events from time to time, e.g. by calling MessageManager::runDispatchLoopUntil () like
MessageManager::getInstance()->runDispatchLoopUntil (100);
A better option is to offload your task to an extra thread and leave the MessageManager alone. For jobs that have an end, have a look at ThreadPoolJob or for continuous tasks have a look at TimeSliceClient…
HTH
3 Likes
This solved the problem, thx!
Ok, but I guess that the point of most command line programs is not to run a MessageManager at all, am I wrong?
1 Like
The answer is always “depends”. E.g. I have a background process, that is controlled via an InterprocessConnection and produces sound. Hence running a MessageManager makes much sense, even without GUI.
But in other instances I have conversion tools, that run without MessageManager, both is possible.
It wasn’t clear in the OP, if a MessageManager is needed…
In my case one wasn’t needed. Hence my first direction was to avoid the juce_initializeMacMainMenu part (which I didn’t end up trying because I used your solution even without needing a MessageManager).