Handle asynchronous output in Qt console

[epatters]

This is my first cut at having the Qt console place post-execution output before the current prompt. It seems to work based on my testing with threads that print text, although the formatting is sometimes imperfect due to the kernel's buffering. Still, it's an improvement, I think.

This addresses issue #476.

[minrk]

I'm still getting output in the input area when I do:

import threading, sys, time
def printer():
    time.sleep(2)
    print 'hello'
    sys.stdout.flush()

threading.Thread(target=printer).start()

Then 'hello\n' gets appended to my next input line.

Is it not possible to write directly into an existing <div>? I don't know enough about how the HTML of the rich widget works, but it seems to me that a structure like:

<div id="<exec count>">
    <div class="input">
        In []....
    </div>
    <div class="output">
        Out[]...
    </div>
</div>

would allow inserting text into the right field to be easier, and ensure that it never goes into an input area. The output messages do contain information about the parent message, so they can know which field they belong to.

[epatters]

@minrk I ran that code five times and it worked for me each time. As a sanity check, can you confirm that it is really broken for you?

As to the larger issue of implementation, it is not possible to write directly into a <div>. I would have to extract a subsection of the QTextDocument as HTML, modify it, and replace it. This combined with that fact that the <div class="input"> tags are specific to the IPython-widget makes me reluctant to attempt this approach. I fear it is actually more complex.

[minrk]

Crap, sorry for the false alarm. I was using master when I ran the test before. It is indeed fixed, and well behaved.

Ah, I didn't realize that the Qt Widgets were only a sad imitation of a real HTML viewer, and don't support super basic features like DOM traversal or in-place modification. Fair enough, then.

[epatters]

I think the Qt guys consider QTextEdit's use of (a subset of) HTML to be an implementation detail. They needed to support rich text, so they went with HTML, but they expose very, very little of the machinery behind it.

Qt is a nice toolkit, but there are definitely times when I am frustrated by its opaqueness.

[epatters]

@fperez I know this issue is of interest to you. If you have a few spare cycles, would you mind trying this branch out? If not, that's fine, and I'll go ahead and merge it (barring any other objections).

[fperez]

testing it now, I see some weirdness... I have to flush something urgent now, in a couple of hours I'll have more feedback.

[fperez]

@epatters, I see this kind of misbehavior:

In [2]: debug
> /home/fperez/scratch/error.py(45)RampNum()
     44     step = (end-start)/(size-1-tmp)
---> 45     result[:] = arange(size)*step + start
     46 

6

ipdb> !size

what happened was that I typed !size and the 6 appeared before my own prompt.

We definitely want the output to be written before the next input prompt, but in this case it seems to be moved over above the current one. I don't know if the logic to disambiguate those two cases is problematic, but right now the behavior seems somewhat erratic and inconsistent:

ipdb> print 1
1
[ 0.2  0.2  0.2  0.2  0.2  0.2  0.2]

ipdb> print step

the print 1 produced the 1 below the print (as expected), but the print step gave the output above the print (wrong).

[epatters]

Ah, blast. I'll look into that tomorrow.

Thanks for trying it out.

[epatters]

@fperez Should be fixed now. I can use %debug successfully on this branch.

[fperez]

Looks perfect to me, I can't seem to find a way to break it, while it was trivial to cause glitches before.

Merge away!

Many, many thanks, this was really a critical piece of the usability puzzle for the qt console. Excellent work.