You can clone with
HTTPS or Subversion.
Hey @epatters, I talked about this one with @rkern at Enthought last Friday during the datarray meeting, I don't know if he filled you in. Basically it's what I see as the last 'big' thing remaining to tackle in the Qt console that hinders everyday usability, but I'm not quite sure if it's easy or not to fix.
The problem is that, due to the asynchronous nature of our design, every now and then we end up with output printed after the input prompts, and that messes up any further input. It's easy to 'unwedge' the console with Esc, but new users may get confused. And the place where it happens most often is when we are doing raw_input from the kernel, such as in %debug scenarios. In such cases, doing Esc has the additional disadvantage of erasing what is often useful information from the screen, like code listings.
Because this issue comes from the underlying asynchronous structure of the system, no amount of sleep() calls sprinkled around is going to ever quite solve it. But I was wondering if the console could be restructured so that it would consist of two textedit areas joined together (possibly with some light visual cue like a thin separating line or a light background change). The input area would always be the one at the bottom, and it would only display the prompts from either raw_input() (which we get in a special message) or from the client itself. And all printed output would always go to the top one, which would get 'filled in' above the input prompt (since that one would always be at the bottom).
It seems to me that this simple separation could do the trick. Does it sound reasonable, and if so, how hard is it to implement?
Thanks for any thoughts you might have on this one.
I agree with the premise. The present situation is a serious usability annoyance in need of a fix that goes beyond a liberal sprinkling of time.sleep statements.
The idea you propose is interesting--a kind of IRC-client console interface--but is a very significant departure from the present design. This widget would actually be much easier to implement than the console-style one we have now, but it would require a great deal of new code, which at this point I don't have time produce. Still, I think this would be neat experiment for me or someone else to toy with in the future, as a complement or alternative to the true console interface.
The solution I propose is to have the widget insert stream messages above the current prompt, if there is one. Note that I would not take care to distinguish which prompt produced the messages; everything goes just above the current prompt. This is straightforward to implement and seems like a reasonable solution.
That (@epatters' suggestion) seems like a good solution for now. We might want to revisit this after 0.11, but I think we should focus on getting what we've got ready for release.
Great. I should be able to get this done over the next couple weeks.
Resolved by pull request 526.