-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Den 2018-03-06 kl. 12:59, skrev Mike Sheldon: > Hi Rinigus, > > On Mon, Mar 5, 2018 at 8:23 PM, rinigus <rinigus....@gmail.com > <mailto:rinigus....@gmail.com>> wrote: > > 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, bu t > then should stabilize. If there is anyone from UBPorts interested in > joining Presage development - we would be happy to get any help :) > > > That's interesting, you might also be interested in taking a look at m y > (unfinished) Skeyer branch: > > https://code.launchpad.net/~michael-sheldon/ubuntu-keyboard/skeyer-pro totype > > That uses saidinesh's libskeyer to provide auto-correction (and > eventually swipe style input), this provides spatially aware correctio ns > (i.e. it knows that 'b' is next to 'n' on an English keyboard so would > suggest 'and' as a correction for 'abd' instead of Presage's predictio n > of 'abdicate'). I think the strongest approach would involve a > combination of the two, using Skeyer for correction and Presage for > prediction.
Just a quick note that for presage the hunspell predictor provide basically the correction functionality. But I see no problem adding libskeyer as a predictor too in contrast to have them in another loose combination of predictor and corrector. ljo > Few general questions though: > > * If I want to test the keyboard, is there VirtualBox (or some oth er > similar) emulator for Ubuntu Touch / UBPorts? > > > As far as I'm aware there isn't a working emulator image, however you > can run the Ubuntu Keyboard on a standard desktop system as well; afte r > compiling and installing the plugin as normal and running maliit-serve r > you can start any QT app with the environment variable > 'QT_IM_MODULE=maliitphablet' to invoke the keyboard. > > * Do you have some mailing list or some other means where we could > discuss joint projects with UBPorts developers? > > > There's a pretty active Telegram group here: https://t.me/ubports (I'm > on there, but not very involved) and the UBPorts forums > here: https://forums.ubports.com/ > > > > * If we would like to port UBPorts keyboard, would it mainly requi re > changes > in https://github.com/ubports/keyboard-component/tree/master/qml > <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. > > > From memory there shouldn't be too much that needs changing; most of t he > QML is standard QtQuick, there should only be a few things using the > Ubuntu Components that'll need replacing, e.g. the language menu and > anywhere that's using Ubuntu's grid units for sizing. > > > > 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 oth er > similar chars (\n) with the exception of plugins/ko. Do you happen > to have some API that could be used to plugin different tokenizati on > library, same Presage for example? > > > As far as I recall our tokenization was pretty simple, we basically ju st > allowed each plugin to define a list of characters to tokenize on (so > for example Chinese could tokenize on different characters from > English), it probably wouldn't be difficult to replace that with > tokenization performed by another library. > > Hope that helps :) > Mike > > > But before going into major porting of the keyboard, would be good > to know what Jolla's plans are regarding their keyboard. They shou ld > be back in the office now after a great time in Spain, hopefully w e > can hear back. > > Best wishes, > > Rinigus > > On Mon, Mar 5, 2018 at 4:18 PM, Mike Sheldon <m...@mikeasoft.com > <mailto:m...@mikeasoft.com>> wrote: > > Hey Rinigus, > > I've been out of the Jolla ecosystem for a while (since my pho ne > 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 specifi c > questions you have about that. > > Cheers, > Mike > > On Wed, Feb 28, 2018 at 7:14 PM, rinigus <rinigus....@gmail.co m > <mailto: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 publish ed > keyboard using this library. I think its a great developme nt > and together with @ljo we have been helping @martonmiklos to > make this plugin better. Please note that below, I speak f or > myself and I haven't checked whether these questions even > make sense with others. > > At present, the released plugin has been enhanced by makin g > it fast through using different language model storage/que ry > 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 workin g > 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 > <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 an d > 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 i f > it's gonna be without any use. > > So, to summarize, I would like to hear what's an opinion o n > the raised issues by those who know. Would be great to kno w > plans and comparison of jolla-keyboard with the current > Maliit UBPorts/LuneOS versions. > > Best wishes, > > Rinigus > -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTZ3t2nVJPW4yk01pSFwiflpVc48gUCWp7HHAAKCRCFwiflpVc4 8jkYAJ9vp+SABobvEOEXNTGEVZHM5hqjYQCgrkUEOzr+krwBhjUX2W5Ym4WchWM= =Fi9e -----END PGP SIGNATURE----- _______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
