Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate input area in Qt Console #476

Closed
fperez opened this issue May 27, 2011 · 6 comments
Closed

Separate input area in Qt Console #476

fperez opened this issue May 27, 2011 · 6 comments
Assignees
Milestone

Comments

@fperez
Copy link
Member

fperez commented May 27, 2011

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.

@ghost ghost assigned epatters May 27, 2011
@epatters
Copy link
Contributor

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.

@takluyver
Copy link
Member

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.

@fperez
Copy link
Member Author

fperez commented May 27, 2011

On Fri, May 27, 2011 at 8:46 AM, epatters
reply@reply.github.com
wrote:

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 sounds like a perfect plan. In fact, I think what you describe
is 99% of what I had in mind functionally, so if you think you can
have a shot at it, that would be phenomenal.

Cheers,

f

@epatters
Copy link
Contributor

Great. I should be able to get this done over the next couple weeks.

@fperez
Copy link
Member Author

fperez commented May 28, 2011

On Fri, May 27, 2011 at 5:54 PM, epatters
reply@reply.github.com
wrote:

Great. I should be able to get this done over the next couple weeks

Fantastic, many thanks. Ping us if anything arises we can help with,
or that you'd like feedback/review on. This one's a biggie for
getting 0.11 out, IMO.

Cheers,

f

@epatters
Copy link
Contributor

Resolved by pull request 526.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants