[Issue migrated from SourceForge | ID: 3440549 | Submitted by 'jamshark70']
[http://sourceforge.net/support/tracker.php?aid=3440549]

Hm, I thought I had opened a tracker item for this, but I guess not.

In scel, if you try to open a document programmatically inside the action function of a Qt GUI object, the "open" operation doesn't complete. SC correctly passes the instruction to Emacs to open a buffer with the file's contents. After the buffer is open, Emacs calls back into SC to bring the document to the front and add the new document object into Document.allDocuments.

I confirmed once upon a time, using debugging statements, that Emacs sends the callback request, but sclang ignores it. The callback request is sent through the following chain of functions:

(defun sclang-make-document ()
(sclang-perform-command-no-result 'documentNew sclang-document-id)
(sclang-document-update-properties t))

(defun sclang-perform-command-no-result (symbol &rest args)
(sclang-eval-string (sclang-format
"Emacs.lispPerformCommand(%o, %o, false)"
symbol args)))

(defun sclang-eval-string (string &optional print-p)
"Send STRING to the sclang process for evaluation and print the result
if PRINT-P is non-nil. Return STRING if successful, otherwise nil."
(sclang-send-string
(if print-p sclang-token-interpret-print-cmd-line sclang-token-interpret-cmd-line)
string))

(defun sclang-send-string (token string &optional force)
(let ((proc (sclang-get-process)))
(when (and proc (or (sclang-library-initialized-p) force))
(process-send-string proc (concat string token))
string)))

Normal, interactive code evaluation from Emacs also eventually goes through sclang-send-string -- just to point out that the callback request is coming through sclang's normal input FIFO, nothing special about it. Something about Qt blocks either receipt or execution. (What's even more puzzling about that is, I also tried deferring the Document.open for one or two seconds, and the callback still failed to execute if it was even just scheduled from a GUI action function! So it's something deeper than just blocking input for a moment after the user's click. See the third example below.)

"d = Document.open(somePath)" completes the callback successfully if it's evaluated from any context except a QT object's action function.

The following contrasts GUI.swing vs GUI.qt. GUI.swing exhibits the expected behavior.

f = {
var w = Window(\test, Rect(800, 200, 100, 50));
b = Button(w, w.view.bounds.insetBy(4, 4))
.states_([["click"]])
.action_({
d = Document.open(thisProcess.platform.startupFiles.last);
});
w.front;
};

GUI.swing;
SwingOSC.default.boot;

f.value;

d // -> a ScelDocument(startup.scd)

Document.allDocuments;
--> [ a ScelDocument(SCLang:Workspace), a ScelDocument(SCLang:PostBuffer), a ScelDocument(startup.scd) ]

d.close;

GUI.qt;
f.value;

d // -> a ScelDocument(_/home/dlm/.config/SuperCollider/startup.scd_)

Document.allDocuments;
--> [ a ScelDocument(SCLang:Workspace), a ScelDocument(SCLang:PostBuffer) ]

// now this is where it gets REALLY psycho
// why would the callback still be blocked, 2 seconds later?

f = {
var w = Window(\test, Rect(800, 200, 100, 50));
b = Button(w, w.view.bounds.insetBy(4, 4))
.states_([["click"]])
.action_({
AppClock.sched(2.0, {
d = Document.open(thisProcess.platform.startupFiles.last.debug("opening now"));
});
});
w.front;
};

GUI.qt;
f.value;