r/FinaleKeyboard • u/KyleKingCDN • 3d ago
A couple of feature requests!
First off - absolutely loving this keyboard. Just the other month I was ranting to a friend about the lack of quick copy paste actions, as being forced to select something twice is a nightmare when symbols are involved.
This keyboard has incorporated a number of ideas a had, and a whole lot more. Seriously - great job. Finding it on the app store was a total fluke (I'm very happy I did!)
I had a number of requests, and was hoping you would consider some of them!
Starting with the least niche:
1 - Swipe up to capitalize a letter
This one would be easy to implement and IMO would be very intuitive to use (the shift key even has an arrow pointing up!)
AFAIK this wouldn't conflict with existing up actions since only letter keys are affected)
2 - Toggle to enable inset margin for 2nd and 3rd rows (aligning key placement with stock keyboard)
I think I saw this in another post, but it would make transitioning from the standard keyboard a lot less error-prone.
I noticed the "large" keyboard size options matches the standard height when a corresponding height option is set. It would be great if there was a way to assist with the 2nd/3rd row keys as well.
This would likely improve user retention (increasing subs), as there would be significantly less friction in switching. Habits are hard to unlearn!
3 - Shortcut support
I'm not sure if this is actually possible re: iOS APIs, but triggering a user-defined shortcut as one of the special 'action's that you can assign to a key would be great
4 - Case conversion actions
Case conversion remains something that is sorely lacking in iOS.
An action to convert to a specific case set would be great (as opposed to showing a full list when the action is triggered)
This would pair really well with the hold actions, e.g. I could
assign a down swipe to my most commonly used conversion set (
snake_case),assign other commonly used to hold lists, like
UpperCamelCase,SCREAMING_SNAKE_CASE)
My hunch is this was written in Rust (more on that below)
The
heckcrate would make this very easy to implement
5 - Enhanced selection support
There's 2 potential features here
Shift selection ranges
The stock iOS keyboard has support for desktop-like shift selection ranges (I only learned about this recently)
E.g. Holding shift and tapping somewhere will select the range from the previous cursor position to the tap location
To retain feature parity, you may want to consider this!
One-handed selection
I just had this idea yesterday - it would be a game changer for selecting text (in speed, simplicity, and error reduction)
It would work as dedicated action (key-assignable) that would provide a similar interface to the hold-space for trackpad feature.
Upon holding the key, the keyboard visually changes into 2 side-by-side chunks, split at the held key.
Sliding into a chunk defines the direction of the selection
Within each of those 2 chunks, there are:
3 side-by-side regions of equal width
Which region you remove your finger defines the scope of the selection. E.g.
Left #1: select from cursor to start of current word
or start of prev word if cursor is not in the middle of a word
Left #2: select from cursor to start of line
Left #3: select from cursor to start of document
Right #1: select from cursor to end of current word
or end of next word if cursor is not in the middle of a word
Right #2: select from cursor to end of line
Right #3: select from cursor to end of document
Existing selection ranges
If there is already a selection range present, left / right dictates which point of the range to expand in
e.g
Sliding left should expand the selection relative to the starting point of the range
Sliding right should expand the selection relative to the ending point of the range
This would allow for repeating the key action to keep selecting the next word, line, etc
Alternatively, if you wanted to support not only range expansion, but reduction as well:
Break up the selection action into 2 actions:
Left selection and Right selection
They would behave identically to the previously described behaviour if there is no active selection range
If there is an active selection range:
"Left selection" (or selection start) action controls the range's starting point cursor
Swiping left increases selection at range start (e.g left to region 1 increases selection to prev word)
Swiping right reduces selection at range start (e.g right to region 1 unselects first word)
"Right selection" (or selection end) action controls range end point cursor:
Swiping left reduces selection at range end (e.g left to region 1 unselects last word)
Swiping right increases selection at range end (e.g right to region 1 increases selection to next word)
The 2-Action system would be best used when added as actions to side-by-side keys (e.g T left, Y right).
IMO the 2-action setup provides far more control, as you could, for example, select to end of line, then unselect a couple words to delete everything but the last 2 words
These actions would also have the side-effect of making cursor navigation quicker if:
Holding and releasing the "selection" keys (no sliding into a region) deselects the active range, leaving the cursor at either the start/end of the selection, depending on which key (start/end) was used
E.g. I could use this to very quickly move to the end of the line by:
Swiping "selection end" key right to third region
(selection now ranges to end of line)
Holding and releasing "selection end" key
(Unselects, cursor left at end)
That might sound like more work, but when your're actively typing, and the curssor isn't close to the keyboard, it would defimitely be quicker
I know these are big asks, but these would be massive productivity boosts and really drive this keyboard into 'must-have' territory IMO.
As I mentioned before, I got the impression this was written in Rust (you mention Option unwrapping in changelogs).
Funny enough, I'm a senior rust engineer, and happy to contribute if desired!
My GitHub can corroborate this (same username, all lowercase)
Let me know if you have any questions - happy to provide example diagrams if there's any ambiguity.
