In current release version of Obolo Chwerty Keyboard, deadkey on shift layer doesn’t work as intended.
Intended behaviour:
Deadkey + Ọ = X
Deadkey + Sh = H
Deadkey + Ch = Q
Current behaviour:
Deadkey + Ọ = Ọ
The Deadkey works on other layers but not in the shift layer.
Can someone please take a look at the code and help me identify the problem.
Your desktop keyboard replaces “x” with “ọ”, so that when you type the “x” key, you actually get an “ọ” character. You then use the “]” key as a means to get an actual “x” character by typing the “]” key followed by the “x” key. (The “]” key is actually producing a “]” character, so it’s not technically a deadkey, but you’re using the combination of the two characters in the same way that a deadkey would work.)
For your mobile keyboard, you have put the “x” character as a longpress key on the “ọ” key (which is in the position that “x” would be on a QWERTY keyboard). That is a reasonable place to put this character (which I assume is not used in Obolo, except for English loanwords). Therefore, you don’t really need to duplicate the way that the desktop keyboard produces the “x”.
As to your question, I’m not sure exactly what interaction isn’t working the way you intend, but here’s what I tried. Since you really only need one deadkey (that is, you don’t need to treat the key you’re using as a deadkey differently for the default, shift and caps layers), I changed your three rules to all generate dk(1). Then I changed the three rules producing “x” or “X” to all use dk(1). This seemed to work for those cases. So, if you want to keep the deadkey on your touch layout, this is the approach I’d suggest.
Here are the changes I made:
+ [NCAPS T_ENG] > dk(1)
+ [SHIFT NCAPS T_ENG] > dk(1)
+ [CAPS T_ENG] > dk(1)
dk(1) + [NCAPS T_X] > 'x'
dk(1) + [SHIFT NCAPS T_X] > 'X'
dk(1) + [CAPS T_X] > 'X'
You’re right.
Agreed.
Sounds good to me. I will try if out from my own end and give you feedback. Thanks.
It’s not resolved. The keys continue to output what is on the keycap instead of the required underlying characters.
@drowe Please help. Only the CAPS layer responds to the deadkey. Default and Shift layer do not respond.
Hi @katelem
FYI I think the keyboard maintainers @drowe and @Lorna are currently in team meetings, so it may be a week or two before they get a chance to reply.
I’ve just sent it as .zip to your mailbox.
Hi @katelem, has this issue be resolved for you? If not, please respond to this topic; otherwise it’ll be closed in three weeks.
@makara I’m looking at the issue. I’m currently in meetings and travelling, but after that hopefully I’ll be able to reply before 3 weeks are up!
@katelem I’ve looked at the code and what I suggested before doesn’t seem to work now. Perhaps that’s because I upgraded to version 16 of Developer. If I replace dk(1) with "[X]" in all the rules I listed in the Nov2022 post above, I get the intended result (although with the [X] showing up on the screen).
But I really think that you (and your users) will be better off if you remove the deadkey from the mobile layout (along with all the deadkey-related rules in the .kmn file), since there’s already a provision using longpress keys to type all the original letters. This will make the keyboard simpler.
As much as I’d like to dig into this more, I really don’t think that it’s a good use of time.
The deadkey was working well before recent updates. I will remove the deadkey but I will like you (Keyman) to improve the pop-up delay. Compared to other keyboards, it usually takes longer for a longpress key to come up. That slows down typing. That’s why deadkey is preferred in fast typing.
I will also like to wait a little for the longpress “hint” feature to be implemented before removing the deadkey so users transit smoothly.
Thanks.
@katelem, thanks for the feedback!
It’s on our agenda (see section C5029.4) to tweak the popup delay (and perhaps make it configurable for accessibility reasons).
This topic was automatically closed after 20 days. New replies are no longer allowed.