Helium314 / HeliBoard

Customizable and privacy-conscious open-source keyboard
Apache License 2.0
1.86k stars 68 forks source link

Long press return/send behavior on "enter" key #839

Open b02860de585071a2 opened 3 weeks ago

b02860de585071a2 commented 3 weeks ago

Is your feature request related to a problem? Please describe.

Certain apps or input fields have varying behavior with the "enter" key, especially when comparing single-line vs multi-line input.

For example, messaging apps typically use the key as a dedicated "send" key, while in long-form text editing it acts as a return/line break (\n or <LF> basically).

To prevent users from being locked into a single function, some keyboards have a long-press return or shift+return function. This would input a line return when the "enter" key is acting as "send", and vice versa.

(This is not easy to describe with words or search for duplicates, let me just show an example of how gboard handles it)

Here is gboard in multi-line mode, where the "enter" key is functioning as a line break. We can we that holding the key down lets us input a "send"/"enter"/"submit"/whatever:

QPv7Il700Vl0nuFhf5uufkIV6VolAowl.png

Comparatively, here is HeliBoard in the same scenario. We can see that this is not an option:

yKd8G87LlZnhWhM77T4OWUals6cBzvnQ.png

And here is the opposite situation (key is "send", no way to input a line break):

MTW3TlstS5fSzLsLfiGuPZyARfVgeF0h.png

Describe the solution you'd like

I would like for a way to access both functions (send/submit and return/line break), so that certain input fields are not annoying to work with.

Ideally this would be a long-press action, similar to the example shown above. Using shift as a modifier may also work, but I imagine it would be more complicated to program + introduce some weird bugs?

To me, I see a "perfect" solution being just a simple floating action, very much like how the other functional keys already behave.

Use case

This is already an annoyance with certain messaging apps, or with text fields on various websites. Relying on random sites to properly define their input field classes is not really an option.

Describe alternatives you've considered (if any)

Currently I have no other way to get around this, besides keeping a second keyboard installed for one single function.

b02860de585071a2 commented 3 weeks ago

Side note: I've seen a few people mention similar behavior for the clipboard, but I couldn't find an existing issue for this specific case.

I searched for "return", "enter", etc, but I'm sure I'm not the first person to bring it up.

ccoVeille commented 3 weeks ago

I like your feature request and the fact you helped to discover a quick access to smiley and clipboard. I had no idea it was possible. There is indeed a … on the key but I have never noticed, and of course tried

codokie commented 3 weeks ago

what version of the app are you using?

could you name an app/website in which there should be an return/line feed key instead of a submit button?

b02860de585071a2 commented 3 weeks ago

what version of the app are you using?

2.0-alpha1

could you name an app/website in which there should be an return/line feed key instead of a submit button?

That usually comes up on web forms - I'll have to find a public one for you (or just create a test page myself if I have time).

For the other case (have LF, want send/submit as secondary option), I grabbed a couple random messenging apps off F-Droid to test with when originally submitting. Briar will let you create a dummy account + group to compose messages, and replicates the behavior I mentioned.

Helium314 commented 3 weeks ago

I remember there is already some shift_enter key code in the app (from AOSP / OpenBoard times). Maybe it's not used properly, or maybe I broke it unintentionally.

Anyway, this might be a more complex thing to do properly, because ideally there should only be a single place where meta states (shift / ctrl / alt /...) are handled.