Comment 2 for bug 1569059

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.