[Feature Request] Integrating KALQ Keyboard Layout

eeriemyxi commented 1 year ago

Download Wikipedia

I have begun to notice its superiority to QWERTY. Any plans to add some basic support for it?

Screenshot_2023-02-28-20-24-15-14_61c78dc80ee02b53007c815fefe993e3.jpg

Julow commented 1 year ago

Would you mind taking care of the implementation ? A layout file looks like this, see the guidelines and examples.

JackDotJS commented 1 year ago

i figured this might be fun to try making 😄 honestly i'm surprised at how easy it was to create a new layout.

its very work-in-progress though, there's several issues i need to sort out still:

where should i add numbers/punctuation keys? i did find this screenshot from the download link in OP's post, so i might just try copying it later.
as far as i'm aware, we don't have a "close keyboard" button anywhere outside of whatever the OS already provides, which is why i've left that one bottom key as a duplicate of the enter key. what should i put there instead? maybe ctrl or fn?
is it possible to define a custom layout for the numeric keyboard to go alongside this?
i'm now left wondering how to deal with how incredibly tall this layout ends up being. in settings, the keyboard height is set to the default of 35%, but it feels closer to 50% with this layout. i'm not aware of any other layout that uses 5 rows like this, and honestly, i'm amazed this worked at all (this is also why I have the config button in a weird spot, in case keys ended up out of bounds or something lol). i did notice some layouts specify their own height for certain rows of keys, so I wonder if that could be used to get the overall height under control... though i wonder why the key height isnt scaled to fit the actual keyboard height to begin with 🤔

eeriemyxi commented 1 year ago

i figured this might be fun to try making 😄 honestly i'm surprised at how easy it was to create a new layout.

its very work-in-progress though, there's several issues i need to sort out still:

where should i add numbers/punctuation keys? i did find this screenshot from the download link in OP's post, so i might just try copying it later.

as far as i'm aware, we don't have a "close keyboard" button anywhere outside of whatever the OS already provides, which is why i've left that one bottom key as a duplicate of the enter key. what should i put there instead? maybe ctrl or fn?

is it possible to define a custom layout for the numeric keyboard to go alongside this?

i'm now left wondering how to deal with how incredibly tall this layout ends up being. in settings, the keyboard height is set to the default of 35%, but it feels closer to 50% with this layout. i'm not aware of any other layout that uses 5 rows like this, and honestly, i'm amazed this worked at all (this is also why I have the config button in a weird spot, in case keys ended up out of bounds or something lol). i did notice some layouts specify their own height for certain rows of keys, so I wonder if that could be used to get the overall height under control... though i wonder why the key height isnt scaled to fit the actual keyboard height to begin with 🤔

To answer the 2nd point, the back navigation button will serve the same function in most cases, so that should be the CTRL key IMO.

And I think @Julow is better suited for answers to other points (I think you're asking where to put the stuff in the configuration code in the 1st point, no?).

JackDotJS commented 1 year ago

@eeriemyxi i was hoping you could answer my first point, since you actually use this layout 😅

eeriemyxi commented 1 year ago

@eeriemyxi i was hoping you could answer my first point, since you actually use this layout 😅

Oh, I thought you were confused about the code. You mean the positions of the special characters as swipe keys? The middle ones are easier to reach, so you could randomly put them there, it wouldn't make much difference where each is. And I see a "123+" key, you could add the second number key layout (or numpad keys layout) to appear by that; special keys to replicate the original layout besides the numpad layout would be your choice, as swipe keys would be mostly used.

BTW, the current work is amazing! Thank you for your interest.

sdrapha commented 1 year ago

The number 3 question, I implemented in my branch a while back. I use my own numeric layout alongside my own alternative qwerty layout. In my aproach, you can have as many numeric layouts as text layouts, and pair them up as needed. I plan to rebase all my modifications on top of the latest build, just didn't have time yet. But I don't know if jullow has any appetite for taking in that modification in particular. Since that would open the doors for more layouts to maintain. I would happily maintain my own alternatives layouts including extra numeric layouts thou. This keyboard is the only keyboard I use now, in all my devices, so I care about it.

JackDotJS commented 1 year ago

update: i've added numbers and punctuation keys (to the best of my ability, anyway 😅)

the keys towards the bottom of the keyboard proved to be a bit awkward, since the numeric keyboard from the original design has more individual keys there, whereas the main keyboard has these larger keys. to solve that, i simply added those keys to the bottom corners of the keys 1-2 rows above, which results in this current design. i'm not sure how well this really works, but for now, it makes the most sense imo.

thoughts?

eeriemyxi commented 1 year ago

update: i've added numbers and punctuation keys (to the best of my ability, anyway 😅)

the keys towards the bottom of the keyboard proved to be a bit awkward, since the numeric keyboard from the original design has more individual keys there, whereas the main keyboard has these larger keys. to solve that, i simply added those keys to the bottom corners of the keys 1-2 rows above, which results in this current design. i'm not sure how well this really works, but for now, it makes the most sense imo.

thoughts?

I'd prefer the key with all the arrow keys in apparent directions between the backspace and enter: Screenshot_2023-03-15-11-09-43-71_320a9a695de7cdce83ed5281148d6f19.jpg

For some reason, these arrow keys on left and right: Screenshot_2023-03-15-11-10-03-97_320a9a695de7cdce83ed5281148d6f19.jpg Trigger instantly, which (the speed) comes handy in many situations. Could you ape that for the right SHIFT key?

BTW, the current work is still amazing!

eeriemyxi commented 1 year ago

I will also appreciate the FN key placed as a swipe key of one of the keys at the bottom: Screenshot_2023-03-15-11-18-35-55_320a9a695de7cdce83ed5281148d6f19.jpg

And other keys like Meta, Alt, etc., there as swipe keys as well.

JackDotJS commented 1 year ago

done :)

eeriemyxi commented 1 year ago

Phenomenal work! Although, I might miss F11 and F12.

JackDotJS commented 1 year ago

did a bit of math and managed to make each row just the right height so the overall height is in line with other layouts :)

Although, I might miss F11 and F12.

i can still add these! where should they go?

eeriemyxi commented 1 year ago

did a bit of math and managed to make each row just the right height so the overall height is in line with other layouts :)

Good to see the new height!

i can still add these! where should they go?

I think each as a swipe key of "h" and "g" respectively would work just fine.

eeriemyxi commented 1 year ago

And you've already covered all the frequent keys, so at this point you could just clone these from the QWERTY layout for full functionality: Screenshot_2023-03-15-19-06-41-73_320a9a695de7cdce83ed5281148d6f19.jpg

Screenshot_2023-03-15-19-06-11-98_320a9a695de7cdce83ed5281148d6f19.jpg

Julow commented 1 year ago

Thanks all for putting time into this!

is it possible to define a custom layout for the numeric keyboard to go alongside this?

Not without some coding. See the switch_numeric defined in srcs/juloo.keyboard2/KeyValue.java, which is associated to an "event" that is handled in srcs/juloo.keyboard2/KeyEventHandler.java

but it feels closer to 50% with this layout

It's 35% of the height of the screen, for a 4 row layout. A 5 row layout is automatically 20% larger. Perhaps this computation is silly ? You can make every rows smaller with height="0.8" for now.

JackDotJS commented 1 year ago

It's 35% of the height of the screen, for a 4 row layout. A 5 row layout is automatically 20% larger. Perhaps this computation is silly ?

i personally feel like the overall kb height should be constant, with the keys resizing to fit as needed. as both a user and a developer, its really jarring to see a keyboard take up half my screen when i know i set it to 35% height.

like you suggested, i already managed to get around it by setting the height of each row manually, but to me, this feels like an improper, hacky solution.

but then again, it's probably not worth worrying about, since there probably aren't gonna be that many layouts (if any, apart from this one) that use more than the usual 4 rows.

JackDotJS commented 1 year ago

btw sorry for the radio silence the past couple days 😅 i've gotten distracted with some things, but i'm hoping i can wrap up this lil project this weekend.

though i still wonder what should be done with the numeric pad. since Julow mentioned it, i could probably try figuring out how to add a custom numeric layout with some code, but i'm not sure if i should be messing around with the inner workings of the project like that. my java experience is very limited, and i've never done anything related to android development 😵‍💫

personally, i'd like to leave this as a simple, basic layout addition. but at the same time, it's hard to imagine that's ideal for anyone who genuinely wants to use this layout.

sdrapha commented 1 year ago

i personally feel like the overall kb height should be constant, with the keys resizing to fit as needed. as both a user and a developer, its really jarring to see a keyboard take up half my screen when i know i set it to 35% height.

I disagree, I have layouts with 4 rows, with 5 and with 6 rows. (6 rows is the one I use the most) I don't want to the height to be clamped, and the keys squished. I often alternate between layouts, and to have them take the space they need is a feature, not a defect. Squishing the letters would be a defect in my opinion. I know the math to get different sizes layouts to match can be done (if that is the desire), and it's just once. not a big deal. To remove the ability to have different sizes ( when wanted ) would be a bigger issue.