search

Helium314 / HeliBoard

Customizable and privacy-conscious open-source keyboard
Apache License 2.0
2.3k stars 89 forks source link

Space swipe to toggle numpad layout, with side bonuses #950

Closed devycarol closed 2 months ago

devycarol commented 2 months ago

This patch was honestly just a quality-of-life improvement for test-driving the D-pad toy, but it turns out this is pretty nifty to have for the numpad in addition to (eventually) the D-pad. It will greatly simplify cloning the numpad later on.

I've added a space-swipe gesture to toggle the numpad. It's one-and-done, so you don't need to worry about it rapidly changing back and between. Would you like me to make the language slide work the same way? I feel it cycles layouts way too rapidly, to the point where "landing" on the right one is super tedious. Whereas repeated swipes are not that difficult to do, especially since most people have at most 2 languages.

This required implementing toggling logic for the numpad. A side effect of that is the numpad key and symbols long-press can now be used for sliding input—the latter actually had a bug beforehand where it'd show the trail, but not return to the previous layout on release. It works pretty flawlessly now as far as I can tell.

I've proposed a change to the bottom row of the numpad to take advantage of this:

Etc:

If you wish to apply the step-minimum from the language slide to the numpad one and/or a one-shot implementation of the language slide, it'd require sizeable re-tooling in a way that'd be hard to keep track of and migrate to KeyboardActionListener later on (as far as I can tell). I don't think that's necessary, since the fast-typing cooldown applies across the board.

As I implemented the toggling logic, I noticed but didn't address that the emoji and clipboard layouts don't have any sort of state-memory—they always return to the non-shift-locked alphabet layout. This can be annoying if you enter the clipboard layout from the numpad and then hit the 'exit' button, for example.

Helium314 commented 2 months ago

I've proposed a change to the bottom row of the numpad to take advantage of this:

  • The 'symbols' key is replaced with 'numpad', matching its predecessor layout.
  • Key-widths, likewise, are adjusted to match.
  • 'Equals' has the functional background color now. I plan on putting the (functional) d-pad key symmetrical to the numpad one in the default symbols layout, so that should line up nicely. Only giving numbers the numeric/character background is best for legibility in my opinion.

@BlackyHawky you implemented the numpad and probably put a lot of work / testing in the layout. Do you have any comment / opinion on this? From my side the changes are ok, but I barely use the numpad.

Would you like me to make the language slide work the same way?

There is still #656, which I haven't even properly looked at....

devycarol commented 2 months ago

The toggling logic also allows for a toolbar key, so I've added that as well.

Across the board, the fallback behavior in the phone and number keypads seems to work just fine—layout just doesn't change.

devycarol commented 2 months ago

Bug: the toggling breaks when the state is reloaded from, say, a change of screen orientation. Working on a fix.

BlackyHawky commented 2 months ago

@Helium314 First of all, thank you for asking my opinion.

@devycarol The ability to change view by swiping the space bar is a great idea. 👍 By the way, for even more personalization, perhaps in the future we can extend this functionality to the view of emojis, symbols and so on. 🤔

Just a few comments:

devycarol commented 2 months ago

I think that's a good point. Layout-switch keys universally display the layout they'll go to when clicked, at least in the main keyboard view. I guess I got carried away with what I implemented 😅

Toggling will remain used for the toolbar key, but it's unnecessary to use that key in the numpad layout itself since there are already 2 other toggling methods. And on further reflection, "the key does different things depending on how you got here" is not in good taste for main layouts.

There was an idea of "later, add the ability to lock-into the layout via the toggle key during sliding input from a different one," but that'd require a significant hard-to-keep-track-of re-tooling that's—again—unnecessary, since there are already numerous other toggling mechanisms.

I'll change it back to 'symbols', sliding input should still work.

I much prefer the alignment defined previously; is it a matter of taste or is it useful for some other reason?

Part of it was to ensure the numpad key stayed (somewhat) aligned with its previous position, which is now moot. The other reason is that variate widths for keys in the bottom row can be disruptive, but with the other change eliminated I don't think the justification is strong enough. There's a case about equally as good to ensure the widths align with the rows above, so I'll go ahead and revert that as well.

BlackyHawky commented 2 months ago

Great, I'll let you continue with your work. If you need an opinion, don't hesitate.

devycarol commented 2 months ago

Thanks for stopping by!

devycarol commented 2 months ago

@BlackyHawky Oh, but the key colors.

Could we change the background of the 'symbols' and 'equals' keys to the functional type? I think the keys should only be character-colored if they're numbers. Making the symbol key 'functional' better matches its predecessor the numpad key, and 'equals' will align better with the d-pad key once it's added. (And its fellow symbols are also functional.)

BlackyHawky commented 2 months ago

Really sorry, I forgot to update my comment above. 😅

I share your opinion of changing the color of these keys. 😉

devycarol commented 2 months ago

Alrighty! I don't anticipate any further changes on my part.

Helium314 commented 2 months ago

Will have a look tomorrow (evening / Europe time). Today I don't want to see any more code, after coming home from work and then working 6 hours straight on another app...

Helium314 commented 2 months ago

If you wish to apply the step-minimum from the language slide to the numpad one and/or a one-shot implementation of the language slide, it'd require sizeable re-tooling in a way that'd be hard to keep track of and migrate to KeyboardActionListener later on (as far as I can tell). I don't think that's necessary, since the fast-typing cooldown applies across the board.

I think a step minimum for the numpad toggle would be good, but it looks like a main issue is that in KeyboardActionListener you don't know when the swipe was ended. Is this correct?

Helium314 commented 2 months ago

As I implemented the toggling logic, I noticed but didn't address that the emoji and clipboard layouts don't have any sort of state-memory—they always return to the non-shift-locked alphabet layout. This can be annoying if you enter the clipboard layout from the numpad and then hit the 'exit' button, for example.

I never properly looked into this, but I've always had the impression that the KeyboardState is much more complicated than it needs to be. If this is the case, then I think such state-memory for clipboard could be added as part of simplifying the KeyboardState. In the past I've done such simplification with a few classes when migrating them to Kotlin.

devycarol commented 2 months ago

I think a step minimum for the numpad toggle would be good, but it looks like a main issue is that in KeyboardActionListener you don't know when the swipe was ended. Is this correct?

Yes.

Helium314 commented 2 months ago

Yes.

Possibly onUpWithDeletePointerActive could be changed to a more generic function like onEndSwipe(keyCode).

But maybe this should be done in a separate PR, when making the key swipe part of the interface more generic. Keeping track of (is-in-swipe) states in KeyboardActionListener at first glance appears to do the trick, but needs to consider that there can be multiple pointer trackers and multiple swipes simultaneously.

devycarol commented 2 months ago

Right. Using the delete slider at the same time as the forward-delete slider is the funnest thing in the world 😅 Coming soon :)

I think you're right about how to migrate that logic. It's something I could do later, unless you really want a step minimum right away. I just haven't had any issues without one, and it'd be one more thing to keep track of in the pointer state that I'd enjoy not worrying about.

devycarol commented 2 months ago

How would that be done by the way, a JSON property like "horizontalSwipe"? And then it'd override sliding input and app settings? Curious if app settings would even need to change that much.

I also see the possibility of an omnidirectional swipe. I once experimented with that on the trackpad slider and it was mad fun but also mad buggy. Intense zig-zagging, frequent crashes...

That'd require some way of knowing where visual line-breaks are, not just line-ends. I know iOS has a 1:1 thing for moving the cursor in a text box.

Helium314 commented 2 months ago

I think you're right about how to migrate that logic. It's something I could do later, unless you really want a step minimum right away. I just haven't had any issues without one, and it'd be one more thing to keep track of in the pointer state that I'd enjoy not worrying about.

Step minimum is not necessary right now. I think it would be good, but not needed. And implementing it now would mostly be a waste of time. I think I'll open an issue on the adjustments I had in mind for the key swipe interface.

How would that be done by the way, a JSON property like "horizontalSwipe"? And then it'd override sliding input and app settings? Curious if app settings would even need to change that much.

I haven't put much thought here. So far my idea was to add a setting that would switch from popup keys to unexpected keyboard style (with some limitations). Ideally it would also allow for custom (key-independent) actions like in #532 (might be simple by ignoring the key code and only using direction).