On Wed, 2018-02-28 at 21:14 +0200, rinigus wrote: > Hi, > > I have a question regarding the longer term plans for keyboard > development in SFOS. Namely, @martonmiklos has brought over Presage > predictor to SFOS and already published keyboard using this library. > I think its a great development and together with @ljo we have been > helping @martonmiklos to make this plugin better. Please note that > below, I speak for myself and I haven't checked whether these > questions even make sense with others. > > At present, the released plugin has been enhanced by making it fast > through using different language model storage/query mechanism, using > relatively small size of n-gram database (English 5MB, Estonian > 10MB), made asynchronous to ensure that the user's input is not > lagging behind, and just extended with Hunspell speller as an > additional "predictor". All is in the testing / bugfixing stage. In > longer term, with the right effort, we could get very well working > open-source predictive engine and keyboard. > > I am trying to understand how the pieces fall together and I am not > sure 100% whether I do. I can see that SFOS uses proprietary jolla- > keyboard and the developed Presage input handler extends it. Which is > fine, but maybe we could go deeper and do better. > > From looking around, Maliit has adopted keyboard developed by Ubuntu > Touch as a reference, corresponding Maliit repo https://github.com/ma > liit/keyboard . In addition to UBPorts, the same keyboard is used by > LuneOS. This design already supports Presage and Hunspell, also done > in asynchronous manner as we are testing for SFOS now. It has support > for quite a few number of languages, pinyin, and emoji. I do not know > how this design compares to the internals of jolla-keyboard and maybe > someone can share their knowledge regarding it. I would expect that > it was developed on the top of Maliit available at the time of J1 and > kept as it is after that.
Short recap on history. Original Maliit reference plugin was developed for Nokia N9, I was the lead developer for that. On Jolla I wanted to do more QML centric one, based on lessons learned on original Maliit keyboard and another virtual keyboard at Nokia. Ubuntu keyboard went another way and continued from the old code base, think it was also made public after Jolla keyboard had proceeded a lot. > Now, I do wonder what is the long term plan with the keyboard > development? From the outside of Jolla, it seems to me that it would > be wise to join forces with the others and develop this component > together. Each OS in question has their own styling, but that seems > to be possible to apply on top. Not sure if it would be worth much redoing Jolla UI on top of another plugin. Would make the base more complex by requiring extendability of different things. What matters more is ability to reuse different input method engines on different keyboards. While not being too familiar with the current state of maliit-keyboard project, I'd expect it to be somewhat easy anyway. Qml can reuse list model regardless of api elsewhere. For integrating input to jolla-keyboard it's mostly just implementing handler functions for key press/release/click. For general western input that is currently little over 100 lines, some more for updating layout geometry to the prediction engine. > Its not trivial to compile the latest Maliit on SFOS (they switched > to CMake based builds and few cmake configs are missing in SFOS right > now), but I expect that its possible with some effort. Just don't > want to spend too much time if it's gonna be without any use. Guess it depends on what you're up to. If CMake modules make sense on other projects then PRs welcome (some already packaged). If for keyboard you want to have ability to tinker and use a different one then just go ahead :) Maliit framework supports also having multiple plugins, but on Sailfish we've relied on just using the single one that is found, multiple ones might trigger code that hasn't been much tested for a while. _______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
