Backspace doesn't work properly in SwiftKey

[simonpoole1]

If you type a few letters into the board in SwiftKey and then try to delete, you have to hit delete multiple times before it starts deleting from the board. It seems like SwiftKey is maintaining its own internal buffer of letters you've typed, and deletes from its own buffer first. The app doesn't receive the keypress at all until that buffer is cleared. Probably we need to find a way to tell the IME not to maintain its own buffer.

[yourealwaysbe]

Did it work ok before e4f8eee1154f25afa2ce276a0f8f1d24c2311538? I removed some code that was explicitly forcing a delay in repeated keypresses as it led to weird interactions and i didn't see what it could be for.

[yourealwaysbe]

What happens if you add the following code to the ScrollingImageView class?

@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
    BaseInputConnection fic = new BaseInputConnection(this, false);
    outAttrs.inputType = InputType.TYPE_NULL;
    return fic;
}

@Override
public boolean onCheckIsTextEditor() {
    return true;
}

I think this would set the input type of the board as being basic with no buffering. See this post.

It might be that Forkyz should turn the ScrollingImageView into a proper inputable view, instead of the activities receiving key presses.

[yourealwaysbe]

Can you try the latest commit 9ac95577b8cccf190ac18bf82792d45e549dcf1f? -- it has the input type set to null.

[yourealwaysbe]

I just stumbled across this in the onKeyUp documentation:

Key presses in software keyboards will generally NOT trigger this listener, although some may elect to do so in some situations. Do not rely on this to catch software key presses.

I'd had the naive idea that using the native keyboard left it up to the system how to generate keypresses, and alternatives such as voice could be used. However, digging into this (briefly) i have the impression that the software input methods on Android revolve around editing blocks of text (ultimately they have to implement methods to append strings and replace substrings). This doesn't map well onto editing a crossword grid -- i imagine it could be done, but it would be messy to include all the clue changing navigation and what not within that.

Possibly the SwiftKey issue relates to a basic misuse of the soft keyboard. Reverting to implementing an in-app keyboard might be clunky, but the only proper way of doing it. We could bring back the Shortyz keyboard, but then find some replacement for the deprecated KeyboardView class. On the one hand, a layout of buttons isn't so complicated. On the other, KeyboardView.java is thousands of lines.

I was looking into the IPuz format which includes a field specifying which characters are allowed to be played as responses. It would be cool to have a dynamically generated keyboard that includes only valid characters. Even though i only play English crosswords, it's kind of a bummer Forkyz and the .puz format are limited to ASCII.

An annoying part of this is that the NotesActivity has an EditText for the notes. This uses the soft input method whether you like it or not. Conceivably the scratch and anagram boxes would work with the string-editing approach of input methods, but it's not something i'm too exciting about digging into. In the old days i had it hide the in-built keyboard when the notes box was focused, which is probably the best way to do it now (and it makes sense -- notes is free-form, scratch etc are still limited to permitted response characters).

[yourealwaysbe]

Hmm -- but an in-app keyboard doesn't help if a user would prefer QWERTZ over QWERTY for example. Surely there's a nice way of receiving single character events that doesn't involve everyone writing their own suite of keyboards.

[yourealwaysbe]

Ok, i accepted that soft input methods deal in text replace edits rather than key presses -- it makes sense for the majority of applications. I rewrote the in-app keyboard (plus arrow keys) and removed the soft input method support. I think it's pretty much done and is in the in-app-keyboard branch.

The arrow key layout is for aesthetic reasons only. I also removed the large display layouts because i don't have a reasonable way of testing them, and i didn't want to maintain something afaik no-one uses. Feel free to submit pull requests addressing these if it doesn't suit you.

edit: ok, found one issue in key repeat, will work on that. editedit: think fixed.

[simonpoole1]

Awesome - thanks for sorting that!