Usability improvements to Qt console

[fperez]

Currently the Qt console is tricky to use with multiline cells recalled from history because it's very easy to go 'off the edge'. If the cursor reaches the top or bottom line and you do up/down once more, you jump to the next cell. When recalling history that's the desired behavior, but when you've already edited a cell, it's jarring to get bumped out of your editing context due to a single arrow movement.

I don't know how easy/possible it would be to implement, but my idea is the following: the console should detect when a cell has been made 'dirty' by editing (any typing other than arrow movements, pasting, etc), then the behavior should change. At that point, the cell boundaries should become 'hard', preventing the cursor from exiting unless the person clears the cell. Basically, once the cell is being edited, it should feel like a little text editor that doesn't lose its content without some drastic action.

[rkern]

It could be made like the readline behavior. If you edit a "cell" in the history, that edited text remains even as you move up and down in the history. When you execute or cancel, the original text takes its place back in the history, and the new text (if you executed) appends to the history.

[epatters]

I second Robert's idea.

[fperez]

On Fri, Apr 8, 2011 at 11:32 AM, rkern
reply@reply.github.com
wrote:

It could be made like the readline behavior. If you edit a "cell" in the history, that edited text remains even as you move up and down in the history. When you execute or cancel, the original text takes its place back in the history, and the new text (if you executed) appends to the history.

That sounds good, but do you mean to suggest not stopping the cursor
at cell boundaries once the cell has been edited? Part of what's very
jarring is the jumps that happen if you accidentally up-arrow through
the first line, and your big multiline cell gets replaced by 'ls'.
Even if we can recover it by going back down, I think ui-wise it would
be better to 'lock' the cell from exit at that point.

But I have no idea if that's easy to do in qt or not...

[rkern]

I'm always leery of preventing people from doing stuff, especially if the only way to "unlock" things is to execute something or lose what you've written. Someone might legitimately want to go up or down in the history while they're in the middle of typing something. This is particularly important when the history is from previous sessions so the user cannot simply scroll up to see it.

Rather, I think the principle to follow is one of "safe exploration". They can move around freely without losing their work. Yes, it might be visually jarring from time to time, but that's all.

[fperez]

OK, I can agree to that. I think I would prefer a "safety stop" once the cell has been edited, just requiring perhaps an extra Ctrl-arrow to get out, or somesuch... But if that's hard to implement, it's OK.

Do you guys have any available cycles to implement this over the next few weeks? I don't know enough qt to do it... But I think it's still an important usability limitation of the console to lose edits from an accidental up-arrow. It has happened several times to me and it's really annoying...

People have been very impressed when I've demoed the qt console, but things like this still make it a bit unappealing for actual heavy-duty work. I think we're very close, but not quite there.

But since I can't really do the work myself right now, I can only ask :)

[epatters]

I will implement this, Fernando.

For now, I will go with the readline approach since that satisfies the principle of least surprise. If time permits, I will add a configuration option for some kind of lock, with a keybinding (Shift+Up/Down?) to disable it. But I think that the locking should be off by default.

[fperez]

On Sun, Apr 10, 2011 at 10:03 AM, epatters
reply@reply.github.com
wrote:

I will implement this, Fernando.

For now, I will go with the readline approach since that satisfies the principle of least surprise. If time permits, I will add a configuration option for some kind of lock, with a keybinding (Shift+Up/Down?) to disable it. But I think that the locking should be off by default.

This sounds great, Evan. Many thanks!

[epatters]

@fperez
Should the locking apply to any "edited" cell, or only those with multiple lines? I think the latter makes more sense, and would fit in nicely with the Enter/Shift+Enter distinction for multi-line inputs.

Also, you mentioned above that there were certain usability issues making the console difficult to use for "heavy-duty work". Could you create tickets for any such issues that you can recall? We would like the Qt console to provide as nice an experience as possible.

[fperez]

On Sun, Apr 10, 2011 at 2:34 PM, epatters
reply@reply.github.com
wrote:

Should the locking apply to any "edited" cell, or only those with multiple lines? I think the latter makes more sense, and would fit in nicely with the Enter/Shift+Enter distinction for multi-line inputs.

Go with the latter, that sounds good.

Also, you mentioned above that there were certain usability issues making the console difficult to use for "heavy-duty work". Could you create tickets for any such issues that you can recall? We would like the Qt console to provide as nice an experience as possible.

I will, thanks. This was the biggest, I'll make one as I think of
them, mark them with the qtconsole label and tentatively assign them
to you. Feel free to un-assign any of them you feel you can't deal
with for any reason (or re-assign to someone else if you think they
can handle it better).

Thanks!