[SailfishDevel] keyboard development

[rinigus]

Hi Pekka

Thank you very much for the reply. I have inserted my replies below.


> 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.
>

OK, so we now where the development diverged and the branch between Jolla
and Ubuntu (now Maliit default).


> 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.
>

It will surely require time and, in ideal world, is a needless duplication
of an effort in a small OS which has many other components that would need
more attention. I agree with that aspect.


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.
>

Indeed, we have now the input method that links presage to jolla-keyboard
written by @martonmiklos. We could probably go a long way by expanding
Presage with correct handling of Unicode string, implementing tokenization
in Presage to support more languages and exposing this functionality to the
plugin. This work can be reused then by any keyboard, not even limited to
Maliit.


> 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.


Indeed, it depends on the priorities. Personally, I am interested in
developing open-source prediction/correction engine since I am using a
ported device and want to have good and working solution without Xt9. Throw
in the fact that Estonian probably doesn't have Xt9 support and you have my
main interest formulated. However, in the background, I also like our
approach since we rely on open-source libraries and this is transparent to
the users community as well as gives us an ability to reuse the components
elsewhere.

When talking about one of the main user-interacting component in the OS,
such as keyboard, the transparency does become an important part of the
discussion. Large fraction of jolla-keyboard code is in QML and we can see
what QML is doing, if we wish. However, there is a library blob which I
have no way of knowing what's going on there. All I can see is that its
linked to all kinds of other libraries through its dependencies, including
network libraries as well. So, its essentially comes down to the trust that
the version that I have installed on my device doesn't call somewhere with
something. The trust that I do have at this moment. But I do find the
situation far from ideal and would prefer to have open stack for myself and
all other end users in the core components of the OS. In particular, the
parts which are used for communication and user input.

So, when we talk talk about longer-term plans with the keyboard, it would
be important to know whether jolla-keyboard is scheduled to become
open-source component in foreseeable future or not. If it is not then I
presume we should have a discussion within the community on what to do
about it and whether anyone wants to work on adapting open-source
components. Which, in the end, is the burden for the community that would
lead to investment of time and effort that would come at expense of work on
applications.

Best wishes,

Rinigus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20180307/e3638353/attachment.html>