Sorry about the Fl::add_fd() issue. I had no idea about the side effects. I have now moved that call, so Fl::add_fd() will not be called until the user actually launches and external editor. This should no longer interfere.

When I read that launching FLUID from /tmp will lock up, I couldn't believe it. But I checked, and yes, it's true. I attached the debugger and it hangs in `void Fl_Cocoa_Screen_Driver::open_display_platform()`, calling `[NSApp run];`, 1728 in Fl_cocoa.mm. Since it wasn't able to open a window, it will hang here forever, waiting for messages from that not existing window.

So the issue must be when creating the window, maybe not having permission to do that. I tried other apps from the test directory, and they have the same issue! FLUID in command line mode in /tmp however runs fine for me.

Looking at the Console output (scary stuff...), it seems that apps get a "Darwin Role" assigned by the "RunningBoard" which determines if an app interactive, but launched from "/tmp", FLUID's role is "Set darwin role to: NonUserInteractive". This looks very suspiciously like one of those boxes that Pandorra keeps throwing at me, and I am somewhat reluctant to open it.

cp build/Xcode/bin/Debug/fluid.app/Contents/MacOS/fluid /tmp

cd /tmp

./fluid  (hangs)

./fluid -h   (works)

./fluid -u test.fl   (works)