Complex key flags: "large" and "bold" ?

[ValerieLehane]

Hi! This is a feature request.

When defining complex keys, the flags "small" and "dim" are available. In some use cases, I can see where I would want a particular key to have no swipe actions. Because the whole point of Unexpected Keyboard is to have swipes, the keys seem to reserve a little bit of room inside their perimeters for the swipe indicators to fit in. In cases where a user wants a given key to have no swipes, the key still preserves that space -- and it should continue to preserve that space, so that key labels continue to have consistent sizes and offsets, unless otherwise specified. That's where the complex key flags would come in, if I'm understanding their function correctly. If possible flag values "large" (as in the label uses more space, reserving none for swipes) and "bold" (opposite of "dim") were added, it would add more customization for single-function key use cases.

I do find it a little strange, though, that you can't use these cosmetic flags for non-complex keys, if I'm understanding the docs correctly. Was there some intent, perhaps, to add flags that aren't about modifying the appearance of the key? That would explain it, if so. If not, wouldn't it make sense to allow the use of flags on normal keys?

[Spike-from-NH]

I think this is the philosophy:
•The tap is the essential action of the key and has the boldest, largest legend. If these aren't big enough, you go into Settings and increase the factor.
•Swipes are secondary and have less prominent legends.
•If you replace the clipboard picture with "Paste", you might want to reduce its size further to avoid overlaps.
•You don't want to magnify swipe legends versus tap legends.

[ValerieLehane]

I get all that. I must not have been as clear as I hoped.

The reason to not increase the size of the central keycap/indicator/legend (whatever we're calling it) for all keys is that they're the size I want them to be already, on those keys that have both tap and swipe actions, and making them bigger would result in overflow/overlap.

However, among those keys that only have a tap action, and no swipes, there are sometimes keys that I would like to have a larger legend. For instance: The layout I use has some single-action, tap-only keys. The home, end, page up, page down, compose, and arrow keys have symbols that are pretty small. Because they aren't sharing their keys with any swipe actions, there is plenty of room that the symbols could be expanded to fill.

If those symbols were made larger universally, though, they would start to overlap in other layouts where those symbols are on keys that have multiple actions, so making these particular symbols universally larger would not be a good thing to do. Noticing that there already is a flag to make a legend smaller, though, a possible solution presents itself: In addition to the "small" flag, which already exists, a "large" flag could be made.

[Julow]

Thanks for your issue :)

I think what you want is to control how the layout renders, not the symbols.
The 'small' flag is intended to make a symbol smaller because they would otherwise render wrong on any layout, it's not intended to be used to control how a layout looks.

For example, if a key was added automatically (from settings or languages or after an update), the larger symbol wouldn't be alone on its key anymore. And what if someone wants to change how one of the default layouts renders ?
Also, defining a layout where all keys are "complex" keys would be tiresome as the syntax is quite heavy.

I'd prefer to have a settings option that makes symbols bigger when possible instead of adding styling options within layouts. Anyone would be interested to work on this ?

[ValerieLehane]

Does "bigger when possible" here mean "if there are no swipes, render the symbol bigger?" Because that sounds like it would be pretty cool convenient way to do it.

I wish that I could offer to do the work, but it's outside of my capability, due to lack of a working dev environment, lack of a real keyboard for writing code, lack of ergonomic environment to support doing the work (I live on a broken couch), aaaand also I don't even know how, lol. If I had all those other things, I could fork and learn, perhaps. Maybe one day.

Meanwhile, I hope you don't feel pressured by all these feature requests. This is a pretty great keyboard, and I just wanted to share an idea, but if people make requests you don't have time to fulfill, I hope that you won't feel bad about saying no. Thank you for all of your hard work!