Hi Rinigus,
I just wanted to bring to your attention the Nemo Mobile maliit-plugin
keyboard (https://github.com/nemomobile-ux/plugins). It is fully
open-source and it can run on SailfishOS devices.
Only thing that we are lacking is the prediction support and some small
features. We are considering about moving to new maliit keyboard(based
on ubuntu maliit) or then
qtvirtuakeyboard(https://github.com/qt/qtvirtualkeyboard).
I am really interested in your keyboard project and would like to
contribute to it so that Nemo would also have updated keyboard!
BR,
-eekkelund :)
On 03/07/18 12:11, rinigus wrote:
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
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
