Disable all GUI in GUI App?

General JUCE discussion
1

Hi all,

I’m wondering if there’s a blanket way to disable any gui windows from popping up in a gui app, just like how the console app “intrinsically” does it.

Basically, I’m hosting plugins in the gui app (because I need the message thread to work for async updates and what not) but I don’t actually want any gui elements opening.

Many thanks!

1 Like
2

I’ve decided it’ll take too much “under the hood” work to get the juce messaging system hooked up differently but if anybody else is looking into this there’s a good post here (for OS X) http://stackoverflow.com/questions/2154600/run-nsrunloop-in-a-cocoa-command-line-program

3

Take a look at MessageManager::runDispatchLoopUntil. You can call this in a loop and will basically have messaging up and running. We use it for unit tests that run without GUI.

4

luzifer this is splendid thanks! For anybody looking into this here’s some setup code below (in the Main.cpp file generated from a Juce Console App project)

/*
  ==============================================================================

    This file was auto-generated!

    It contains the basic startup code for a Juce application.

  ==============================================================================
*/

#include "../JuceLibraryCode/JuceHeader.h"

class Tick : public Timer
{
public:
    Tick()
    {
        startTimer(1000);
    }
    
    void timerCallback() override
    {
        DBG("timer");
    }
};

//==============================================================================
int main (int argc, char* argv[])
{
    // init message manager and message queue
    MessageManager::getInstance();
    
    {
        // add timer (uses message loop)
        Tick t;
        
        // run message loop
        MessageManager::getInstance()->runDispatchLoopUntil (5000);
    }

    // avoid TimerThread leak assertion
    DeletedAtShutdown::deleteAll();
    
    // avoid MessageManager leak assertion
    MessageManager::deleteInstance();

    return 0;
}
5

I’ve encountered an issue with this setup, just wanted to check if anybody has some knowledge on the matter.

My dev machine is running OS X 10.11 and thus I compile my projects in Xcode using the 10.11 OS X SDK (but with a OS X 10.7 Deployment Target setting).

The reason I’m using a console app to do some background rendering is because I don’t want any ui elements appearing & I don’t want to have to write code (most likely macros) to manually disable the ui stuff.

This works fine when running the executable in 10.11 but when my coworker runs it in 10.10, it crashes when attempting to run the ui loading code:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff87151282 __pthread_kill + 10
1   libsystem_c.dylib             	0x00007fff8bd7ab73 abort + 129
2   libc++abi.dylib               	0x00007fff8a15ea21 abort_message + 257
3   libc++abi.dylib               	0x00007fff8a1869d1 default_terminate_handler() + 267
4   libobjc.A.dylib               	0x00007fff8a3196c6 _objc_terminate() + 103
5   libc++abi.dylib               	0x00007fff8a1840a1 std::__terminate(void (*)()) + 8
6   libc++abi.dylib               	0x00007fff8a183d48 __cxa_rethrow + 99
7   libobjc.A.dylib               	0x00007fff8a3194e4 objc_exception_rethrow + 40
8   com.apple.AppKit              	0x00007fff873b571d _NXCreateWindowWithStyleMask + 704
9   com.apple.AppKit              	0x00007fff873b53c2 _NSCreateWindow + 187
10  com.apple.AppKit              	0x00007fff8728cb81 -[NSWindow _commonAwake] + 1365
11  com.apple.AppKit              	0x00007fff8729c3e0 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 803
12  com.apple.AppKit              	0x00007fff8729be17 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 829
13  com.apple.AppKit              	0x00007fff8729ba6b -[NSWindow orderWindow:relativeTo:] + 159
14  BackgroundRender              	0x000000010456cc8a juce::NSViewComponentPeer::setVisible(bool) + 138
15  BackgroundRender              	0x00000001044435ef juce::Component::setVisible(bool) + 687

I’m thinking this might be some sort of issue between the 10.10 & 10.11 system libraries?

6

Hi, have you tried inheritting from JuceApplicationBase to deal with event loop?