Project roadmap

[Stypox]

What	Status	Linked issues	Description
System integration	WIP	#126 #79	Dicio should appear as an assistant app in all places possible. It should also implement STT APIs for keyboards and other apps.
Kotlin, Jetpack Compose, Material 3		#124 #96 #95	Kotlin is more convenient than Java in many cases, and it is becoming the standard for Android development. Jetpack Compose allows building UIs based on state, and has also many more advantages and shorthands, such as not needing separate XML layout files. Both Kotlin and Compose would save development time in the future and probably also help avoid bugs. While migrating to Compose, the Material 3 design should be used.
Natural language processing overhaul		#107 #62 #30	The current natural language processing based on dicio-sentences-compiler and dicio-skill has some limitations. Sometimes it does not capture the user intent so well and it is clunky to work with (especially when used alongside dicio-numbers). Sentences files should be allowed to define and use custom matchers (e.g. one that matches all articles, another that matches only dates and times). Matchers might even be defined from outside of sentences files (e.g. all methods from dicio-numbers will be available as matchers), so this would require to develop an API. Capturing group handling should also be improved, making it possible to e.g. specify the allowed and not allowed words, the minimum and maximum length, ... Repetition like regex's + and * should also be taken into consideration.
Documentation		#78 #74 #24	Documentation is heavily needed to make contributing easier and more welcoming. We should setup a wiki of some sort, add more javadocs to code (especially in dicio-sentences-compiler, dicio-skill and dicio-numbers), and add an About section inside the app with useful information.
Wakeword recognition		#48
Sentences files on Weblate		#46	Weblate does not support skill translations in the current setup of Dicio. Maybe arranging sentences files in a specific way and maybe creating a different Weblate component for each skill would allow skills to be translated. This might require a CI workflow.
Proper Vosk implementation		#128 #131	Users should be able to choose the Vosk model they wish to use and even keep more than one downloaded on their device at the same time. The Vosk website API should be used to obtain available languages and perform updates. Switching between models should be easy and the various system integrations should be able to query available languages.

I created this table to be able to track the most important topics that require work in Dicio at the moment. I also added some basic descriptions to explain what I thought of so far. I will work through these topics one bit at a time.

Since these are quite big topics that require structural changes, if anybody wants to help out, please write a comment here so that we can agree on how to proceed. Thanks!