Hi Kent
Thank you very much for the link. I havenât been through everything but it looks like just a normal (beginner) Keyman tutorial. I am spĂ©cifically looking for new features like implementing Automatic capitalization etcâŠ
Will look into it to see if any new feature is addressed.
Thanks
Ibrahima
Hi Ibrahima,
Yes, it is a basic tutorial. The main new feature it covers is the new method for testing a touch keyboard. It does not automatic capitalization.
Kent
Thanks a lot
About capitamlization I the âstart-of-sentence detectionâ: Casing support
Regards
Ibrahima
We havenât yet planned a workshop for the capitalization features in Keyman 15. I agree that this would be a good thing to do, and so will discuss internally if and when this will be possible.
Thank you very much Marc. Yes, workshops are very useful for people like me.
About capitalization canât we just copy the code here: and paste it into our code since Fulah will behave like English and French as far as first letter capitalization is concerned?
I am also wondering where all the webinars are stored so I can have a look whenever I need to. I remember it was on Vimeo. Any link?
Regards
Ibrahima
I think this is where they all should be: https://www.youtube.com/c/KeymanApp/videos
Iâm not sure what the Vimeo link was.
And hereâs the page from the Keyman 14 webinars: Keyman 14 Launch Webinar Series
Here is a Vimeo link for Keyman training videos:
https://vimeo.com/channels/keyman
But I think the Youtube link has the newest videos in it.
And hereâs an organised page of Keyman Developer videos, mostly centred around the 2020 webinar series currently: Keyman Developer Training Videos
Weâll try to continue updating this page when we have new videos to add.
Yes, that should work pretty well in most cases. Youâll need to make sure you follow the steps there about updating your touch layout as well, so that the caps layer is present and the shift layer functions as expected.
For sure the latest Unicode 15.0 should be included on the next Keyman Developer version.
https://unicode.org/versions/Unicode15.0.0/
regards,
Ilham
@inurwansh, yes, weâve already updated for Keyman Developer 16.0, and we always update the Unicode version with each major release. You can update the Unicode Character Database yourself to a newer version in Tools/Options at any time, as well, and Keyman Developer will work with newer characters even if they are not yet in the version of Unicode that is officially supported.
Another two wish list items for mobile keyboards for the roadmapâŠ
(1) I was considering the general problem of screen real estate to present symbols for selection; a problem that we solve with layers and pop-ups when display space is not sufficient. Then thinking about the ease of working with layers and popups using oneâs thumb, and what motions are easy to make.
I routinely use my thumb to flick through a list of photos back and forth, this motion seems natural and is used a lot in apps. Could we use this approach to change layers? A âShiftâ key could be eliminated entirely, and the user just flicks left or right to change between layers.
Further, the keyboard change key (with globe icon) could be eliminated if an up/down flick motion could change between keyboards. Thus using flicks (if this is what theyâre called) could both recover some real estate by eliminating two keys, and make changing between layers and keyboards easier. 
(2) Another technique to avoid having to change layers and return. Letâs say a row of virtual keys can comfortably fit 10 keys across. But 12 or 14 keys would really be dandy. Wouldnât it be great if you could scroll the row left/right to expose a few more keys?
thanks,
-Daniel
Thanks @dyacob, weâll take these ideas into consideration. Note that flicks will be supported in an upcoming version of Keyman â but these will be key-based, not entire keyboard. We hope to use flick on spacebar to switch languages â but will still require the globe key for accessibility reasons for now.
Keyman.Social
This post is part thought experiment but also a serious, eventual, Roadmap item should the resources ever be available. How can a keyboard app be social? And why should it be? I think Keyman can also be a social app and both the app and its users would benefit from it becoming one. A summary here for consideration.
When I look at the various mobile apps there are a few that have a social component though their primary function is something else that I look at as a model for Keyman. The best example would be my Fitbit tracker which is there primarily to track my steps as I walk. Knowing how many steps Iâve taken encourages me to do more. But being connected to friends, knowing that they can see my steps (or rather the lack of them), and being able to see their steps, motivates me much further. The human nature of being self-conscious and competitive kicks in here. Most importantly, Fitbit doesnât require me to do anything extra really, unlike Facebook, Instagram, or Twitter where you have to prepare something to share and then post it, then monitor a conversation that follows, etc.
Suppose with the Keyman app you could opt-in to start tracking your usage such as keystrokes and which keyboards were used and how much so, and made available on a statistics screen. Typing speed per keyboard could also be calculated and presented to the user on the statistics screen. This could be interesting data for a user (also for a developer to know which keys were most used or least used). If a user could then create an account, the social aspect would be built around sharing this data.
With a user account and profile in the Keyman app, the next step is to connect to friends. With a friend network, you could view the keyboards that a person has installed in a most-used listing, and keyboards marked as favorites. This would be a way to discover new keyboards that you werenât previously aware of. (Friend of friends could optionally be viewed, I find that I donât do this on Fitbit and donât know if itâs possible, so seems less important).
Like sharing a view of steps with Fitbit friends, it would be keystroke counts that are shared. Analogous to âWorkweek Challengesâ in Fitbit, it would be weekly typing challenges. Both typing volume and speed can be tracked. Overall winner, but also most/fastest per specific keyboard.
Globally, the Keyman central site could maintain a leaderboard of who the biggest and fastest typist are. Perhaps a leaderboard of the most used keyboard per language, again helping the discovery of new keyboards.
Without being in a friend network, the local usage tracking could still be useful and give Keyman a minor âgameâ like aspect where a user is rewarded for reaching milestones. Like receiving a star for reaching 1,000 keystrokes, 10k keystrokes, etc. or reaching a set goal (daily, weekly). Offering little rewards to the user would encourage them to use Keyman over other keyboard apps. A âDonate to Keymanâ button can be conveniently placed on these statistics and social pages. Coming into these screens regularly to check updates the user will get lots of exposure to the button and presumably is more likely to eventually donate.
@dyacob, itâs an interesting idea, but I think itâs way outside the scope of where we want to go with Keyman for now. It would also take a very significant investment to make it happen even if we wanted to do this!
I just tested the keyman for android. It is great. I needed to increase the keyboard size, so you should keep that enlarged by default. The only downside was the graphical look or feel was very outdated, not appealing.
Ideally, Iâd want it to work like the regular keyboards on android like SwiftKey (its GUI itâs very nice), but I guess it must be due to technical reasons. And Iâd hope for better phonetic keyboard for PC as we have a phonetic Hindi in android SwiftKey, it auto fills the correct words with suggestions, but that too must be for technical reasons as we canât have word suggestions on the PC.
Interesting ideas, but a couple thoughts:
These ideas are a better fit for a company that is trying to maximize usage to increase profits. Iâm pretty sure Keyman is the result of a non-profit org and that is why some of these ideas seem pretty alien to a product like this.
Itâs cool that Keyman has so many keyboards, but it is not really for people that want to collect a bunch of cool alien looking scripts. In my opinion, Keyman fits a very real and serious need which is to provide a means of communicating for those that are under-represented by major operating systems.
This is to say, Keyman should continue to lean into this non-profit social good vision rather than diverging into a more profit-motive kitschy thing.
Just my 2 cents! I am always happy to see more people promoting Keyman.
With the introduction of LDML, will .kmn files be saved in an XML format? This is the only way that Iâve seen LDML content serialized. If so, will it become possible to then use XMLâs native import and extension mechanisms to develop keyboards modularly?
An example of what Iâm thinking of here with the Ethiopic keyboards, much of the data and logic is common across languages, so an import and extension of the common part would be beneficial for maintenance.
thanks!
LDML is a specific type of XML. The draft specification is at Unicode Locale Data Markup Language (LDML) Part 7: Keyboards . It includes an import element. Perhaps this could be useful in making modular keyboards?
Good questions @dyacob. .kmn files will remain as they are â weâll continue to support them and improve them. Thereâs a big community using them and I doubt theyâll be disappearing any time soon.
There will be a new XML file format (see the draft spec) which Keyman Developer compiles into an extended .kmx file format (called, naturally, KMXPlus). This will be consumed directly by the Keyman apps, so there will be no intermediate .kmn.
The XML format does support <import> but for this round of the spec, we have deliberately restricted the use of imports to shared CLDR data. This is mainly so that we can ensure that the design weâve landed on works before we make life more complicated, and to ease the path for implementation. As soon as we split the keyboard data across multiple files, especially shared files, it makes maintenance a whole lot more complex â but we do want to support this in a future iteration of the spec.
You can start playing with this now, with version 17.0-alpha of Keyman Developer. The new kmc command line compiler will build KMXPlus keyboards, and some aspects of functionality are complete on desktop platforms (Windows, Linux, soon macOS). Touch support will come in 18.0 â just too big a project for us to get it into 17.0.