Language toggle button location

[ronniedroid]

Hello,

I am adding a toggle button to the keyboard
I have already tested locally and it works great, but my question is before I open a PR is, should I put the key on the toolbar (current location) or between the emoji and the space key? I mean the toolbar or the bottom row?

With the voice button active plus this toggle language button the toolbar doesn't look bad, but the clipboard preview doesn't have much room anymore.

Please let me know your thoughts.

Edit: Whatever option we chose, we can also remove the long press from the emoji key and have it on the toggle key to show the language selection dialog.

[ronniedroid]

@naveensingh what do you think?

[naveensingh]

Sorry, I haven't worked with the keyboard in a while. What exactly is this toggle button going to do? How does it differ from the current 'long press to change language' implementation? Is it to move through given a set of languages without launching the language change dialog?

[ronniedroid]

Yes exactly, it cycles the selected languages (From my other PR). It is very useful when you only use two or three languages, as it is faster than having to hold then select one from a dialog.

[ronniedroid]

I have been thinking about it today and I think having the language bottom on the buttom row is better,

• put the , as a popup character in the . key
• put the toggle language key in place of the , key
• move the long press from the emoji key to the newly added language toggle key.

In the Dvorak layout, move the q from the bottom row and put it between the shift and the z keys.

[ronniedroid]

@naveensingh @Aga-C is it ok if I use xml external entities in the keyboard layouts in the xml directory?

For example, importing the bottom, as most of the layouts use the same bottom row, and same goes for the numbers row.

The only thing that might be a problem in this case is the hard-coded path, though I think we can programmatically add the <ENTITY ...> line to the xml files.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Keyboard [
    <!ENTITY commonBottomRow SYSTEM "app/src/main/res/xml/common_bottom_row.xml">
    ]>
<Keyboard xmlns:app="http://schemas.android.com/apk/res-auto">
<Row>
...
</Row>
......
&commonBottomRow;
</Keyboard>

[naveensingh]

@ronniedroid Just so you know I'll start working on the Keyboard soon, I'll be back here then.

[ronniedroid]

Glad to hear that.

Then I will leave modularity for later.

[ronniedroid]

@naveensingh should I work on the toggle button soon before the release? Or should I wait until after the initial release? As it does require some discussion on where to put the button.

[naveensingh]

I don't feel too good about using our limited screen real estate for another language-switch-related button. Your other PR about the language filter already resolves the problem of scrolling through a long list to switch languages, so I don't think this button is necessary anymore.

I'm closing this for now. We'll revisit it if it is requested again. Thanks!

[naveensingh]

Just dropping these here for future research:

• https://developer.android.com/develop/ui/views/touch-and-input/creating-input-method#IMESubTypes
• https://developer.android.com/reference/android/inputmethodservice/InputMethodService#shouldOfferSwitchingToNextInputMethod()

[ronniedroid]

It seems this is a repeatedly requested feature, especially for users like me that switch between languages very often.

[naveensingh]

I'm aware but I still don't like the proposed approach in your PR. The proper way would be to make use of IME subtypes and cycle through them using the switchToNextInputMethod(true) method. This will also help unify language and keyboard switching (see #76).

There's still the problem of adding the language toggle button or gesture. We could rely on shouldOfferSwitchingToNextInputMethod() for that. I'm yet to think on it really.

[ronniedroid]

I see, I myself don't like it when my keyboard switches to another one, as in my mind I like to separate things, but I think you are right on how this should get implemented. I lost my job and my good laptop, I can't really develop for android on my current potato laptop, or I would have tried to do it the proper way myself.

[naveensingh]

No worries, it'll be implemented when it is implemented :)