[SailfishDevel] keyboard development
Leif-Jöran Olsson
ellefj at gmail.com
Tue Mar 6 16:51:40 UTC 2018
-----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.git at gmail.com
> <mailto:rinigus.git at 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 <mike at mikeasoft.com
> <mailto:mike at 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.git at gmail.co
m
> <mailto:rinigus.git at 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-----
More information about the Devel
mailing list