Hi Eekkelund, great to hear from you! As, I am sure, many others in the community, I look on what you guys are doing over IRC. I did look a bit into nemomobile-ux/plugins. Its based on original Maliit plugin, as far as I understood and its not developed upstream anymore. From the lack of response regarding open-sourcing Jolla's keyboard, I presume that the status is the same - we are committed to the eventual release, but don't have anyone to commit to it. Which is fair enough, but, on our side, maybe not the best strategy to wait indefinitely.
As for qtvirtuakeyboard, I don't know much. From grepping the source, it looks like prediction is limited to hunspell, t9, and Asian languages. I don't know about its architecture and how it compares to Maliit. The prediction engine that we develop is OSS and has minimal dependencies, as far as I understand, on Jolla's keyboard. Presage is developed as separate library, so its easy to plugin it to the other keyboards. So, it should be easy to integrate into whatever keyboard you will choose. Also the plugin that we work on can be probably reused in the other keyboards, at least partially, if needed. It looks to me that Ubuntu's keyboard has more developers behind and it maybe good for us to join them to get fully OSS option. I would be interested in switching over to fully OSS predictive keyboard. Don't know how Nemo / SFOS will mix and whether SFOS users would need to have Silica based one. But that we can probably learn later. Best wishes, Rinigus On Sun, Mar 18, 2018 at 10:54 AM, eetu <eetu...@metropolia.fi> wrote: > 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-unsubscribe@lists. > sailfishos.org >
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
