Hi Mike, great to hear from you! I don't have many specific questions yet, but thanks for reply and giving heads up.
As I mentioned in the mail, we have extended Presage with the new language model that maybe of interest to your keyboard implementation as well. Speedup is of the order of 10x, maybe more in addition to the significant reduction on database size. We are discussing also Unicode support by Presage to properly support case-insensitive n-gram search, not via `tolower` as done now. It will probably change the database format to implement properly, but then should stabilize. If there is anyone from UBPorts interested in joining Presage development - we would be happy to get any help :) We could surely share n-gram databases between the platforms. It takes some effort to generate them, including hunting down good corpora and processing them. Would be wise to keep the generated databases in a form that would allow simple re-use of them. Few general questions though: * If I want to test the keyboard, is there VirtualBox (or some other similar) emulator for Ubuntu Touch / UBPorts? * Do you have some mailing list or some other means where we could discuss joint projects with UBPorts developers? * If we would like to port UBPorts keyboard, would it mainly require changes in https://github.com/ubports/keyboard-component/tree/master/qml , icons and schema. Or would you expect some other parts require adaptation? Just an estimate would be fine at this stage. I would expect that the keyboard performs its own tokenization to split between the text on the left and the last word that needs prediction. Later, when Presage is called, strings are put back together and Presage is splitting it to words again. Which, in addition to double effort, can be source of confusion if the split to words doesn't match. From the brief look into the code with the help of grep, it looks like tokens are split by spaces and few other similar chars (\n) with the exception of plugins/ko. Do you happen to have some API that could be used to plugin different tokenization library, same Presage for example? But before going into major porting of the keyboard, would be good to know what Jolla's plans are regarding their keyboard. They should be back in the office now after a great time in Spain, hopefully we can hear back. Best wishes, Rinigus On Mon, Mar 5, 2018 at 4:18 PM, Mike Sheldon <m...@mikeasoft.com> wrote: > Hey Rinigus, > > I've been out of the Jolla ecosystem for a while (since my phone was lost > a couple of years ago), so can't say anything much about the Jolla > keyboard; but I was the lead developer on the Ubuntu Keyboard at Canonical > so am happy to answer any specific questions you have about that. > > Cheers, > Mike > > On Wed, Feb 28, 2018 at 7:14 PM, rinigus <rinigus....@gmail.com> 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/maliit >> /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. >> >> 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. >> >> 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. >> >> So, to summarize, I would like to hear what's an opinion on the raised >> issues by those who know. Would be great to know plans and comparison of >> jolla-keyboard with the current Maliit UBPorts/LuneOS versions. >> >> Best wishes, >> >> Rinigus >> >> _______________________________________________ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >> shos.org >> > > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org >
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
