Is it possible to add the keyboard I have made to the “Add New Keyboard” list in Keyman?
Yes, see Guide: Working with the Keyman Cloud Keyboard Repository for instructions. We look forward to seeing your keyboard online!
1 Like
Hi @Marc,
Thanks! I’m preparing the files for upload. This is a touch keyboard for mobile devices. I guess the .ico file is not needed, correct?
Also, as I test the installation, I notice two issues with the iPad version of Keyman.
- The layout images are not displayed on iPad.
Keyman on my android phone can display them.
- Kayman on iPad does not provide the “Help link” and the “QR code”.
Keyman on my android phone has both.
Are these expected?
@Marc said you can help me upload files to Github.
Here are all the files. Do I miss anything?
(Again, I saw an ‘.ico’ file was listed on Step 2: Organizing the Keyboard Files. But I guess it is not needed for the touch keyboard, correct?)
Main folder:
Source folder:
Welcome folder:
I have forked the project to my Github file. Looking forward to the next steps!
Is this a new keyboard? If so, you’ll need to call it something else since there is already an sil_hebrew keyboard. We do already have an .ico file in the sil_hebrew keyboard folder.
If this is just adding a touch layout for sil_hebrew, then this mostly looks fine. However, you should not commit the kpj.user file.
It looks like you now should follow step 3 (Step 3: Submitting a GitHub Pull Request) and then one of us can evaluate your keyboard.
Hi @Lorna,
This is a new keyboard. There is SIL Hebrew keyboard for Desktop, but not made by me. Mine is touch keyboard for mobile devices and tablets. I did not see the SIL Hebrew keyboard in the list.
What name do you suggest for the keyboard and how to change the names?
Change all files names?
Change the name here?
And here?
Do you have suggestions for naming keyboards?
Here is the description of my keyboard:
This keyboard is designed for Biblical Hebrew. It provides all Hebrew consonants, vowels, and cantilations. It follows the mapping of the Biblical Hebrew (SIL) keyboard.
In addition, the “Ctrl” layer contains all consonants and vowels. It is sufficient in most typing cases. The “Ctrl + Shift” layer marks some ambigous signs, such as Qamets and Qamets Hatuph. It outputs the same results as the “Ctrl” layer.
The folder/filename that you use cannot be a duplicate of any other keyboard. The folder/filename are used internally in Keyman as the id. If you want this keyboard to go WITH the existing Hebrew (SIL) keyboard, then it would be better for you to modify the existing keyboard by adding your touch layout.
If you do that, you need to clone the repo, and then begin modifying the existing files in release\sil\sil_hebrew.
That shouldn’t be too much effort since you’ve already come up with the touch layout. You’ll need to extend the copyright date everywhere to 2021. You’ll need to update the version number everywhere. Currently the version is 1.7.2. Adding a touch layout would be significant enough that you might want to bump it to 1.8 or even 2.0.
Update all the other files as needed.
Otherwise, you’ll need to rename all your folders and filenames from sil_hebrew to something else. If the desktop layout is intended to be the same as Hebrew (SIL) then I really encourage you just to add your touch layout to the existing keyboard so that people will not be confused which keyboard to download.
Thanks, @Lorna.
I’ve been using the Hebrew (SIL) keyboard for years on both Win and MacOS. I install the keyboard from SBL Educational Resources. I did not know the source code is listed in the sil folder at Github here. Thanks for pointing me to that.
Just to make sure I’m doing the most appropriate thing. The touch keyboard I made follows the Hebrew (SIL) keyboard mapping. But there are some minor differences:
Difference No. 1:
The “Normal” state layout for the Desktop version is this:
There is a key ("\") between “Z” and the right “Shift” key. But I’ve never had a physical keyboard that has this key. The official Hebrew (SIL) keyboard manual does not have this key either. The touch keyboard I made does not have this key:
Difference No. 2:
Besides this difference, I’ve also changed the left “Alt” key to “Opt” key, to make it to function as the same as that on a Mac. Functionally, it is the same as the “ALTGR” key.
Difference No. 3:
Also, I’ve added a “Ctrl” layer and a “Ctrl+Shift” layer. These two layers have the same output. I created them. The desktop version of the Hebrew (SIL) keyboard does not have them.
With these differences, do you still recommend me to add a touch layer to the existing Hebrew (SIL) keyboard, or it is better for me to change to another name?
Thanks!
I think since this is based on an SIL keyboard layout I would prefer to integrate your work into the sil_hebrew keyboard. If you would like to email your files…particularly .keyman-touch-layout and your welcome files.
The extra key isn’t actually necessary since it is also available on the key below the backspace.
Hi @Lorna,
I’ve just emailed the entire project to you, in case you might need any files other than you mentioned above.
Thanks a lot!
Correct.
I suspect this is due to the use of capital letters in the file names – make sure the casing matches exactly.
Ideally, Keyman for Android should not be providing either of those as those links only really work for keyboards installed from keyman.com – not keyboards installed directly. @darcy do you think we should correct this?
Once your keyboard is available on keyman.com, the QR code and the help link should be available on iOS as well.
It doesn’t look like so.
I copied the file name to the welcome.html file. They match exactly.
The only thing I did was to change the extension .JPEG to .jpeg, because Keyman Develop asked me to avoid capitalized extension names.
To be safe, I converted them into .jpg file. I also changed the file names to small letters. It did not solve the issue. The layout pictures are shown on my android phone but NOT on my iPad.
The QR codes are auto-generated with the package ID (https://keyman.com/go/keyboard/<packageID>/share)
and the site has a fallback page if the keyboard package didn’t originally come from the site. When we added the QR code feature, it was decided to just show them all the time (regardless of keyboard source)
In 14.0, Keyman for Android doesn’t use the “custom” field of a keyboard package, so we can’t tell if a keyboard package originated from keyman.com or elsewhere.
@Lorna I’ve tested adding mobile support to the keyboard yesterday and it seems like the current version of Keyman Developer does not like a line of code in the Layout (@Marc shouldn’t it be ignored by the compiler as the line causing error does serve a purpose in macOS). See: bug(developer): Key code is never fired for Mobile devices · Issue #4346 · keymanapp/keyman · GitHub.
I like @darcy’s comments here. I think we should probably consider bringing Keyman for iOS’s behaviour into line with this to make the experience consistent on both platforms: showing both the help link and the QR Code even for peer-to-peer installed keyboards. @joshua_horton do you concur?
Share Keyboard: foo shows an example of what opening a QR Code for a peer-shared keyboard looks like:
I disagree regarding help links. I thought the decision was to show the local version of help that was installed with the keyboard package?
Keyman for iOS 14.0 doesn’t use any online help links for packages - for either keyboards or dictionaries. It simply checks whether or not the package provides welcome.htm and uses that. (There are plans to also detect & use .pdfs, but… we’ll see if that lands in 14.0 or not.) That’s one of the big benefits of having everything installed via package, anyway.
I’m… conflicted re: QR codes. I feel like it’s a little awkward to suggest “hey, we can share this via QR code” -> “j/k, you gotta do it locally” for packages we don’t distribute.
In case you’re worried, when Keyman for iOS does update checks, it will note if we distribute a package, even if the user didn’t originally receive/install it that way. (It’ll query for the latest distributed version once ‘reachable’ after a resource’s initial installation.) So, while there may be a very small bit of lag, it’ll be quite accurate in what it notes as QR-sharable. So… I feel like what you’re asking would be a step backward on our iOS platform.
Sounds fair. We should probably move this discussion off this topic but either way I think we should try and sync the Android and iOS experiences here, and I didn’t really realise that the iOS experience was that much better in 14.0 than the Android experience.
1 Like
The issue on this topic has been resolved.
Respectfully, due to the inactiveness of the conversation, this topic is now closed for any further discussion.
Please feel free to create a new topic if there is any question or the issue persists.