Keyboard auto disappear / off button to use the complete display

[Michael]

As the software keyboard takes almost/more than half of the space of the terminal in portrait/landscape mode it would be quite useful to get it out off the user's way in order to use the complete screen for the terminal output.

Unfortunately the only way I found is the left/right swipe "workaround" what is not really obvious. Also doing this doesn't make it possible to use the full display for scrolling.

Alternative suggestions:

A. Use full display for terminal output/scrolling and provide the keyboard button also when the keyboard is visible to switch it off

B. Use full display for terminal output/scrolling and let the keyboard disappear (show the keyboard button) after running the shell command

C. Use full display for terminal output/scrolling and make the keyboard semi-transparent after running the shell command
    (This is how FingerTerm works).

Best
M.

[Michael (mick3-de)]

Ok, someone showed me I can actually swipe down the keyboard sliding down with the finger while pressing and holding a single key. Sorry, but that's a rather hard-to-find way of turning it off as I haven't done it in other apps where the keyboard automatically goes off when the focus leaves the edit area.

Also the now available space in the terminal won't be used for additional scrolling or output.

I would suggest to have an option to use the full area of the screen for terminal output. The input prompt and the previous output could be either moved up/down when switching the keyboard on/off or the input prompt could be overlaid as HUD while typing on the keyboard.

[Stefano Verzegnassi (verzegnassi-stefano)]

Hi Michael,

Thanks for taking some time and reporting this.

Sadly, there is not much we can do at the moment. We are aware that one of the most relevant problem is about the on-screen keyboard, but it's not something that can be controlled from a client application.

1) Keyboard takes half of the available space.
OSK is provided by the system itself. This is not something we can tweak from terminal-app.
Please report the bug at https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyboard

Replying to your suggestions:

A) That's something which has been pointed out during an usability testing run by the UX team.
It has been suggested to keep that button visible when the OSK is not hidden but, at the same time, users are complaining that these floating buttons makes the terminal output unreadable.
I'm going to add "ubuntu-ux" as affected project, so the design team can reply on this.

As per the 'swipe-down' gesture, this is how the Ubuntu Keyboard works. It is not a terminal-app fault if it's hard to discover. Being a system-wide gesture, the shell (Unity 8) should inform the user that the gesture actually exists.
Please report it to the ubuntu-keyboard project (see link above).

B) It does not sound as a viable solution. I'm thinking at a case where user needs to execute multiple "ls" or "cd <path>" commands. Users would have to open the keyboard again at any single command.

C) To be fair I've proposed to re-implement an in-app software keyboard. For sure, this solution would have its pros, but there are also a lot of cons:
- We'd have to provide support for many different layouts. In a long-term this shouldn't be a big problem, but, in a short term, this would take a lot of time we currently need to spend elsewhere (e.g. desktop UI for terminal-app)
- On a tablet, when unity-8 is running in windowed mode, the OSK would be still drawn inside the application window, which means that the OSK would be extremely small and unconfortable.
We can't draw a keyboard outside the application window, since Mir does not allow apps to create extra surface. Even if we could, it would be an amount of work that doesn't make much sense, IMO (i.e. it might require to use Mir APIs, which an app should never need to use).

Sorry for such hard answer, I totally agree this is actually a problem, but the current solution is probably the best compromise we can have for an app which should run on phones, tablets and desktops.

Let's see what the UX team suggests.

[Michael (mick3-de)]

Hi Stefano,

thanks for the detailed explanation. I completely understand that using the system OSK is much simpler especially for the windowed mode support.

But what about the other part of my suggestion, the use of the OSK screen space for the terminal output when the OSK is off?

> I would suggest to have an option to use the full area of the screen
> for terminal output. The input prompt and the previous output could be
> either moved up/down when switching the keyboard on/off
> or the input prompt could be overlaid as HUD while typing on the keyboard.

I worked with fingerterm before and these are the ways (besides from having a builtin vkb) how it's been able to use the full screen for the output.

By the way is the unusual two finger scroll gesture the only way to scroll back/forth the terminal output? How about Shift+PageUp/PageDown? The option to use the default one finger gesture for scrolling as it's more consistent to all other apps? I do more often want to see the complete cmd output than to go through the cmd history.