Usability improvements to Qt console #338

Closed
fperez opened this Issue Apr 8, 2011 · 9 comments

Projects

None yet

3 participants

@fperez
Owner
fperez commented Apr 8, 2011

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.

Contributor
rkern commented Apr 8, 2011

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.

Contributor
epatters commented Apr 8, 2011

I second Robert's idea.

Owner
fperez commented Apr 8, 2011

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...

Contributor
rkern commented Apr 8, 2011

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.

Owner
fperez commented Apr 10, 2011

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 :)

Contributor

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.

@epatters epatters was assigned Apr 10, 2011
Owner
fperez commented Apr 10, 2011

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!

Contributor

@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.

Owner
fperez commented Apr 10, 2011

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!

@epatters epatters pushed a commit that closed this issue Apr 11, 2011
epatters Add 'history_lock' setting to Qt console.
Closes #338
66c6673
@epatters epatters closed this in 66c6673 Apr 11, 2011
@mattvonrocketstein mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014
epatters Add 'history_lock' setting to Qt console.
Closes #338
ba044d1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment