Add configuration page

[martonmiklos]

It would be nice to add a configuration page where some diagnostic data (Word/sec, etc.) can be shown. It shall provide a way to edit the learned words dictionary. The page should serve as a bug reporting page as well.

[rinigus]

This page would be needed also to tune the configuration. There are several options in Presage that users may want to tune. Few of them:

Selector.SUGGESTIONS
Selector.REPEAT_SUGGESTIONS
Selector.GREEDY_SUGGESTION_THRESHOLD

It would be good to decide on how to implement this. Namely, we can have an app with the settings or try to get settings into Jolla's settings app. While I know how to write an app, I am not that familiar with Jolla's own settings system. Separate app seems cleaner for me from the programming perspective. I'll call this module 'app' in the following, but it could be both.

Next, we need to figure out how to propagate changes in settings, cleaning of databases, from settings app to maliit plugin. I would suggest to use the following:

• stop keyboard
• save settings using QSettings by the app for maliit plugin
• start keyboard and let presage plugin use QSettings to load them

Its rather simple solution, avoids conflicts with accessing database from different processes at the same time. Also, we could then skip DBUS interface and the "Clear word cache" issue #1

[martonmiklos]

Here is an example of how to add a settings page to an existing application:
https://github.com/monich/openrepos-clock-settings

I am not sure how to get an application listed there without having an icon on the apps menu.
The hide tutorial patch came into my mind (which hides the icon from the app screen), but the Tutorial app did not even shown in the settings page.

[rinigus]

I was mainly thinking about either completely separate app (regular QML with QSettings backend) or something that will integrate into Settings next to "Text input" (but not Apps settings).

[martonmiklos]

will integrate into Settings next to "Text input" (but not Apps settings).

Ah I see it is much better option.

Regarding to the implementation: what if we would not store anything in the 'app' but implement a DBUS based communication between the plugin and the settings UI? Then we could implement the most of the logic in the plugin and we spare the restart cycles.

[rinigus]

Regarding to the implementation: what if we would not store anything in the 'app' but implement a DBUS based communication between the plugin and the settings UI? Then we could implement the most of the logic in the plugin and we spare the restart cycles.

Well, its harder to implement and, as a result, will take longer time. Since you say that clicking "Clear words" also restarts keyboard, it seems that Jolla considered it as an overkill.

In practice, I would use DBUS or some other communication means if there is constantly a need to transfer data. Changing settings is rather rare event and for that I would prefer simpler solution, if possible.

I can imagine that through QSettings we can implement separate configuration app in few evenings. DBUS will probably take significantly longer, I think.

We could also start with the simpler solution and get to DBUS communication later, if someone is brave to make it. :)

[martonmiklos]

Okay I agree with your concerns. Using the same QSettings from both sides does not require any magic and could be implemented pretty quickly.

[rinigus]

Excellent! I am not planning to work on such app (yet), mainly will first make the new language database accessible for testing through work on packaging scripts.

[martonmiklos]

As seeing the user reports on the local forums one feature related to this came into my mind:
It would be useful to add a page where the user could type a word and list the predictions in a vertical list (kind of table) and list which prediction came from which predictor. So when someone claiming that hey why is it suggesting the particular word we could decide if it came from the ngrams, or from the learned words.