Introduction to the Roadmap
Update: see the latest version of the roadmap In this blog post, I have written up our roadmap for Keyman for the next couple of years. This roadmap depends very much on the resources available to our team, and it will change over time. It is not a promise to deliver by a date, but rather our best estimate as to where we want to take the project. I welcome comments and suggestions on our plans. Many of the dot points here deserve more detail, and as we start work on these, we’ll aim to make the working documents available for design feedback as well. We’ll aim to update this roadmap periodically – perhaps quarterly – as we adapt to the ever changing software environment and priorities shift accordingly.Get Involved
As Keyman is open source, we also encourage you to consider becoming involved. There are many ways you can be involved:- Software developers: jump into our source repository
- Keyboard developers: learn about creating keyboard layouts and submitting your own keyboard layouts to share with the Keyman community
- Testers and users: download the latest pre-release versions at https://keyman.com/alpha and send feedback through our community forums
The Roadmap
10.0 Stable – 30 Jun 2018
- Full open source, stable
- Solidify BCP 47 code install on Windows
- Other bugs to be selected.
11.0 – Jul 2018 – Dec 2018
- Bring KMFL into project
- Target Ubuntu LTS; possible Debian
- Refactor Keyman Engine on Windows core (“Keyman Core”)
- Use in KMFL
- Use in KM4Mac
- Use in Debugger / Command Line Tests
- Bug fixes, compatibility and stability
- Windows – Interop with Metro
- Windows – User vs elevated for install / uninstall
- Web – Look at touch layout multitap performance; tweak usability
- Look and feel refresh, all platforms
- Remove adhoc .json style keyboard install
- Complete iOS and Android code refactoring
- Complete cross-platform consistency evaluation
- Keyman Developer code editor -> remove encumbered code
- Keyman Developer -> use Chromium? embedded web engine instead of IE
- Replace web host form
- Use (existing) internal web server instead of XSL for Project, Help, etc.
- Groundwork for predictive text – design, data collection
12.0 – Jan 2019 – Jul 2019
- Predictive Text
- Dictionary support
- Learning
- Corrections
- Word / phrase completion
- Which platforms?
- Keyman Desktop – use Chromium embedded web engine instead of IE
- Replace web host form
- Use internal web server instead of XSL
- Complete Typescript refactoring for KeymanWeb
- Converters
- LDML to KMN converter
- InKey to KMN converter
- KMN to MSKLC, XKB, macos, etc.
- Touch support on Windows
13.0 – Aug 2019 – Dec 2019
- Optimised input tools: Minority language keyboards as first class citizens
- Swipe-style input?
- Swipes for longpress shortcuts
- Other input tools?
- Double-tap caps lock, etc
- Longpress on Windows / Mac?
- Consolidate Keyman Engine support across platforms
- Streamline UI customisation
- Consistent APIs? Keyman Developer web edition
- LDML editor
- Rewrite of existing tooling
- Desktop host for debug and test
- Native engine on iOS / Android
- Uses portable Keyman Core from 11.0
- Native LDML engine
13 thoughts on “Keyman Roadmap – May 2018”
Jolene · May 10, 2018 at 12:18 pm
This looks great! Very promising… You’ve already a number of the features I’ve been wishing for and planning to request on this list (swipe-style enhanced features for touch entry; and language tools such as dictionaries/spell check and predictive text suggestions two major ones).
I have also been longing to see ways to import keyboards from other platforms & formats, particularly the OS native formats—which I also saw on the list (although Mac was strangely missing?)!
My main request is less specific: basically, make it easier to develop keyboards with some of the more complex features. Ideally involving some kind of GUI, but some renovation of the native description language could also go a long way.
I only wish I had more knowledge and skills to be able to offer this project!
Bol bol · June 29, 2018 at 8:32 pm
I am Not sure yet, may be in the long run, the newly release may be working well. but I am still struggle to learn much about it.
Rimas · October 14, 2018 at 7:43 am
Hi!
I want to suggest to slightly adjust the “converters” goal for 12.0: since MSKLC is pretty much abandonware at this stage, I don’t think there is much use in having a KMN to MSKLC converter. How about a converter into what MSKLC produces instead (or in addition to it)? That is, a way to export your keyboard layout into an installable native keyboard layout driver package for Windows? That would be awesome!
Marc Durdin · October 16, 2018 at 11:03 pm
Thank you for your suggestion. It would be nice to implement, but it’s a whole order of magnitude more complicated; the MSKLC format is a simple XML format that we can easily target. Reproducing MSKLC’s compiler phase to create installable .msi files is a large amount of work so it’s not going to happen with our current resource budget. The value of the work is also somewhat limited given that many Keyman keyboards cannot be converted to MSKLC / Windows keyboard DLL format with full fidelity due to the limitations of the Windows keyboard format.
But we take note of the abandonware status of MSKLC and so may deprioritise the export work — but not the import work. 🙂
Rimas · October 27, 2018 at 4:25 am
Ouch.
Well, MSI creation doesn’t have to happen in an instant. Before that, you’d have to reproduce the actual compilation of layouts.
The problem with Windows as I see it is that there aren’t really other tools which would export native Windows layouts (by “native” I mean similar to those exported by MSKLC – easily installable and not requiring any additional software once installed). Also, that compilation phase, while probably not trivial, is still manageable in the end. With a little help I had even managed to hook a bit of custom logic into it, to make my case of numlock-state-independent keymap possible.
While I fully realize that Keyman can do more than what Windows keyboard layout DLLs support, I also think that doesn’t mean that this somehow obscures these “simple” layouts as a possible use-case. After all, such simple layouts probably constitute the biggest percentage of keyboard layout customization overall.
Marc Durdin · October 27, 2018 at 5:07 am
We do of course welcome pull requests. Support for generating platform-native layouts is just not really the problem we are focused on solving at present.
Keyman Roadmap – October 2018 – Keyman Blog · October 4, 2018 at 9:25 pm
[…] May 2018 […]
Keyman Roadmap – February 2019 – Keyman Blog · February 18, 2019 at 5:04 am
[…] May 2018 […]
Keyman Roadmap – November 2019 – Keyman Blog · November 18, 2019 at 11:47 pm
[…] May 2018 […]
Keyman Roadmap – March 2020 – Keyman Blog · March 8, 2020 at 9:19 pm
[…] May 2018 […]
Keyman Roadmap – September 2023 – Keyman Blog · September 15, 2023 at 9:58 am
[…] May 2018 […]
Keyman Roadmap – February 2023 – Keyman Blog · September 15, 2023 at 9:58 am
[…] May 2018 […]
Keyman Roadmap – March 2022 – Keyman Blog · September 15, 2023 at 9:58 am
[…] May 2018 […]