On Mon, Mar 5, 2018 at 8:23 PM, rinigus <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, but 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 my
(unfinished) Skeyer branch:
That uses saidinesh's libskeyer to provide auto-correction (and eventually
swipe style input), this provides spatially aware corrections (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 prediction of 'abdicate'). I
think the strongest approach would involve a combination of the two, using
Skeyer for correction and Presage for prediction.
> Few general questions though:
> * If I want to test the keyboard, is there VirtualBox (or some other
> 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; after
compiling and installing the plugin as normal and running maliit-server 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:
> * 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.
>From memory there shouldn't be too much that needs changing; most of the
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 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?
As far as I recall our tokenization was pretty simple, we basically just
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 :)
> 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,
> 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.
>> On Wed, Feb 28, 2018 at 7:14 PM, rinigus <rinigus....@gmail.com> wrote:
>>> 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,
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to firstname.lastname@example.org
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to email@example.com
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org