plugins: Handle more key events to improve usability in the Developer Console.
Needs RevisionPublic

Authored by cfoch on Jul 20 2017, 11:54 PM.

Details

Maniphest Tasks
T7784: Developer Console
Reviewers
thiblahute
aleb
Summary

Before this commit, the user had to put the cursor manually at an
editable area (whichever part of the Gtk.TextView after the prompt)
to be able to type something. That could be confusing because it
gave the idea that the console got frozen.

This commit adds the following features:

  • Input a text to the console even if the cursor is at the non-editable area.
  • Delete the text when the backspace key is pressed while the cursor is at the non-editable area.
  • Give freedom to up, left, right, down keys to move around the non-editable area if the cursor is in that area.

Depends on D1794

Diff Detail

Repository
rPTV Pitivi
Branch
developer-console
cfoch created this revision.Jul 20 2017, 11:54 PM
aleb added a comment.Jul 21 2017, 10:26 AM

Give freedom to up, left, right, down keys to move around the non-editable area if the cursor is in that area.

We should not bother with this. If the user presses a key, we should assume it's to interact with the >>> line for entering text. For example if I go with the arrows to some text I want to select, then I press shift+right to select, it will focus the timeline, so not optimal currently. Do you think it's worth to make it work?

aleb requested changes to this revision.Jul 21 2017, 10:28 AM

When I type something when the cursor is not on the >>> line, the input goes to >>>, but the widget should be scrolled at the end so I see what I type.

This revision now requires changes to proceed.Jul 21 2017, 10:28 AM
cfoch added a comment.Aug 21 2017, 8:25 PM
In D1795#36005, @aleb wrote:

When I type something when the cursor is not on the >>> line, the input goes to >>>, but the widget should be scrolled at the end so I see what I type.

For some reason this works as you expect if you press two keys. If you press just one, it does not scroll down.

cfoch added a comment.Aug 21 2017, 8:26 PM
In D1795#36004, @aleb wrote:

Give freedom to up, left, right, down keys to move around the non-editable area if the cursor is in that area.

We should not bother with this. If the user presses a key, we should assume it's to interact with the >>> line for entering text. For example if I go with the arrows to some text I want to select, then I press shift+right to select, it will focus the timeline, so not optimal currently. Do you think it's worth to make it work?

"shift + right arrow" focus the timeline? How did you know that the timeline was focused? Or do you want I add that functionality of "shift + right arrow", if so why?

aleb added a comment.Aug 22 2017, 7:53 AM
In D1795#37904, @cfoch wrote:
In D1795#36004, @aleb wrote:

Give freedom to up, left, right, down keys to move around the non-editable area if the cursor is in that area.

We should not bother with this. If the user presses a key, we should assume it's to interact with the >>> line for entering text. For example if I go with the arrows to some text I want to select, then I press shift+right to select, it will focus the timeline, so not optimal currently. Do you think it's worth to make it work?

"shift + right arrow" focus the timeline?

I meant "shift + right arrow" will focus the >>> line.

cfoch added a comment.Aug 24 2017, 3:34 PM

This is the only commit missing.
I'd expect that "shift + right arrow" selects the text from the start of the cursor to the new position of it. Try to open Gedit and see what happens when you type something, put the cursor at the start of the text and then you press "shift + right arrow".