Tic-80: Remove touch keyboard

[michaeldel]

After having worked a bit with keyboard input in the codebase, I am pretty convinced that the touch keyboard brings much more work and downsides than added value to the project.

Implementing acceptable keyboard input handling is _hard_, for many reasons (layouts, modes, simultaneous key presses, etc.), especially when it comes to touch keyboards for real-time applications (keyboard latency, key size/usability, visual feedback, display orientation and size, etc.).

Secondly I can hardly imagine the touch keyboard being relevant for TIC80, having tested it myself on several Android devices. Writing code with it is barely bearable to say the least, navigating with it is painful as well and the display is not even readable on some screens. There are also close to no suggestions of adding touch keyboard support in the project issues.

To me the only value of TIC80 on mobile devices is playing games, or using a hardware keyboard to really write games with it (even though it will certainly seldom happen anyway).

Finally having to deal with touch keyboard interface when working with keyboard input in the codebase is a real pain, makes fixing bugs and adding new features related to this much harder.

To summarize my suggestion:

• entirely remove the touch keyboard from TIC80
• restrict official mobile platforms TIC80 implementations to SURF, keep a way to compile the project to work with hardware keyboards (and hence not have to deal with implementation details)

[michaeldel]

Also consider third-party virtual keyboard apps such as Hacker's Keyboard.

[nesbox]

Yes, agreed, the touch keyboard is a matter of habit, but I don't like the idea to entirely remove it.
A better way, I think, is to allow a user to choose input source, custom touch kbd/system touch kbd/hardware kbd and etc. Also, on mobile platforms, we could automatically start TIC in the Surf mode, but it's very important to have a possibility to see all the game sources even if you don't want to edit them on mobile.
Another idea is to add keyconfig command to setup mapping between real keyboard (no matter what layout French or other) and virtual TIC keyboard which has only these keys https://github.com/nesbox/TIC-80/blob/master/src/tic.h#L499

[michaeldel]

A better way, I think, is to allow a user to choose input source, custom touch kbd/system touch kbd/hardware kbd and etc.

@nesbox to me that's precisely what removing the homebrewed touch keyboard would allow: either use an usual keyboard (virtual or hardware) or do not use it at all. Re-creating a keyboard ourselves and on top of that providing a “choice” system to deal with our clunky implementation sounds like the wrong idea to me.

After having checked some comments on the app's page on the Google Play Store it looks like most users do not bother using the keyboard at all (and just use the app to play games) or use a much better suited hardware bluetooth keyboard to really type text. I can't honestly imagine anyone using our touch keyboard more than minutes without switching it for another input system or just quit.

That's why I do not really understand the need to keep it, I feel we need to be opinionated here because leaving too much choice here will cost a lot on the long run (in terms of development time), for little to no added value. That's what I experienced on #1019, where having to deal with the touch keyboard on top of the rest would involve way too much refactoring for what it's worth, and that's a pretty elementary feature here, plain text input.

Another idea is to add keyconfig command to setup mapping between real keyboard (no matter what layout French or other) and virtual TIC keyboard which has only these keys

This is reinventing the wheel, but much worse than standard solutions. Manually handling every possible keyboard layout is hell, and really not worth the huge development time and bug inserts involved. Sacrificing the homebrewed touch keyboard really stands out as the best costs/benefits ratio decision to me. (it's not just about different key disposition, the whole keys and modes logic can change from a layout to another).

[kikeroga3]

Personally, I don't use a touch keyboard much.
But, I think it is better to leave the choice.

For example, It is common to carry only a smartphone.
There are few people who usually carry the keyboard.

Young acquaintances said that it was fun to be able to program on their smartphones on the go.
He programs on the touch keyboard for a short time when he is willing.

He made Miko blade with TIC-80 :)

[nesbox]

@michaeldel
So, I made here e4bbc1d a hybrid solution based on your pull request, text input works using SDL_TEXTINPUT and touch keyboard processing moved to sdlgpu.c. Now it works properly with any keyboard layout.

[nesbox]

duplicate of #747

[farvardin]

I cannot see any longer the touch keyboard on android. Is there a way to launch it again?

I personnally wouldn't code anything on my tiny phone screen, but I prefered the appearance of the pixelized keyboard over the default android keyboard.

[nesbox]

There is no way, we will add an option to the config in the next version.