Future of the FlorisBoard project #2314
Replies: 4 comments 3 replies
-
Welcome back. I remain ever excited for the future of Florisboard. Thank you to everyone involved. And Id just like to add here that Im happy to keep running beta and debug builds for testing. |
Beta Was this translation helpful? Give feedback.
-
About the point 5.1 I'm not totally sure to understand the main issue of the aim of Florishboard to be cross-architecture in the Linux world. I can see that compiling a same project nth time is a major issue and stuff. However, it would be possible to rely on GitHub Action to build every version for every architecture of the system (either on demand or per commit) and let this processing time/resources using the unlimited free-resources Github is offering to OSS projects. Another possibility in that is, if you hate YAML workflow's writing, to use a Dockerfile as the source file (kind of) to run your workflow and create all those releases. Anyway, I may understand that you're lacking some knowledge about all this part, and I'd be happy to discuss and help the project with you on Matrix if you want :) |
Beta Was this translation helpful? Give feedback.
-
It's good to see you back with a good plan! I can't wait to see this keyboard evolve into something even better! Thank you for your work! |
Beta Was this translation helpful? Give feedback.
-
I am proficient in italian. I can help you whit the translation . |
Beta Was this translation helpful? Give feedback.
-
Hello everyone,
this is a public announcement which will address the future of this project and what I plan to do to get this project to flourish again. Sadly in the last year this project has grinded to a halt, but I am confident that my restructuring plans will help in achieving my goal. Feel free to discuss any of the topics below or suggest new ideas regarding the restructuring in the comments.
As this announcement is rather long and talks about a lot of topics there is no TL;DR, but I partitioned it into sections, so you can directly jump into the topics you are most interested in:
1 General project development
This project initially started as a fun side project during the first Covid lockdown but since then it has grown immensively. During the last three years there have been a lot of external contributions and help but mainly I was responsible alone for most parts and for keeping the project on track. In the first 2 years this concept has worked out pretty well, however with time and life progressing is not possible for me to do this task alone anymore, especially as the amount of issues and feature requests grows quicker than ever.
Thus I am planning on restructuring the project and want to assemble a core maintainer/moderator team on a volunteer basis who want to spend some of their free time on developing this open-source project together as a team and to make FlorisBoard a truly feature-rich and stable open-source keyboard. There are several different areas which this project needs help in with different kind of requirements, so even if you have no experience in software development you can join the team!
Please refer to the contribution guidelines for updated info on joining the maintainer team!
### Basic Requirements- A passion for seeing FlorisBoard flourish
- Good English skills for team and public communication
- A GitHub account and a matrix.org handle
Role Description
Required Dev Experience
Software Developer (Kotlin) for Core App
Some Java/Kotlin development experience on Android
Software Developer (C++) for NLP Core/Native Core App
C++ development experience
Software Developer (Web) for Community Extension Store (Planned)
Frontend and/or Backend web development
GitHub Issues/Discussions Moderator
None
Matrix Space/Group Chat Moderator
None
Crowdin Translation Verifier
Language proficiency for the language you want to verify
- The Unicode ICU library
- The new C++ module system
- Provide a dockerfile where everything is preconfigured to hopefully circumvent ICU compilation issues. However to this point I have not much experience with docker and am still not too found of this concept, so if possible I want FlorisBoard to be compilable on most Linux machines with minimum trouble and without docker.
- Downgrade to the traditional header/source concept instead of using C++ modules -> this would reduce the clang requirement down to clang-15 or possibly older, improving support drasticallly at the cost of less readable C++ code.
Why Join
You'll have the chance to work directly with me and other team members. While the general idea is for us to work on all kinds of different aspects of the project as a team, if you're particularly interested in a specific area (e.g., UI, extensions, text processing), that's totally okay too!
How to Contribute
Here are the specific roles this project needs help in and their requirements:
How to Apply
Interested? Feel free to email me at florisboard@patrickgold.dev! If you prefer, you can also dm me on Matrix or comment below.
2 Word suggestions
This is the most requested feature by far and thus it was important for me to finally try to implement it for the 0.4 version. However sadly I had a lot of work to do besides this project and I also got stuck in the implementation pretty badly, so in total this grinded the complete development to a halt. As such I will not directly work on the core suggestions anymore until after the 0.4 release to catch up on all the bugs and other PRs again.
In general this means: suggestions will be delayed to 0.5. Yeah I know that's a step backwards again, however if this means I get the project to run again in other areas this is totally worth it. I also get some external help currently for ironing out the most critical issues currently present in the core suggestions, so 0.4 might still launch with an experimental preview of completely on-device suggestions, however I do not promise anything as this depends on several technical factors.
3 New project roadmap
To get this project running again I have also completely rewritten the roadmap. The all-new roadmap contains a completely revised plan for the versions
0.4
,0.5
,0.6
andplanned (unassigned)
, to give you a complete overview of what to expect. As always there are no time frames but depending on external contributions and how the assembly of the core team works some things might be implemented more quickly and some less quickly, however a complete halt like in the previous year should not be happening again.4 Transitioning Matrix Group Chat to Matrix Space
To handle more users in the future and to organize maintainer discussions better, I will change the current FlorisBoard Matrix group chat into a Matrix Space and upgrade the room protocol version from 6 to 9. This will also make it easier to find rooms and we plan to add more rooms later. To avoid bot spam issues like we had two weeks ago, rooms will have both human and auto-moderators in the future. The conversion to the Matrix Space will be implemented sometime next weekend (Oct 26th - Oct 29th) and may cause a disruption of the room availability during the conversion. This will also be announced separately in the group chat itself.
5 Technical insight
This section contains more technical insights into some of the above changes and also goes into technical details. It probably is only interesting to you if you are a developer or generally interested in software development or have other prior technical knowledge.
5.1 The problem with compiling FlorisBoard from source
During the development of the NLP core I heavily relied on 2 technologies:
The ICU library is an imensively useful library for correctly handling UTF-8 data, however it has some big issues:
a. Its binary size: ICU can be anything between 10MB to 50MB per compiled architecture, and if FlorisBoard aims to support arm, arm64, x86 and x86_64 this means we need to compile ICU 4+1 times, which takes a long time
b. The compilation process itself is a bit complicated and sometimes requires different config params on different systems, which is a huge issue for recompilability
The new C++ module system has some significant advantages, especially regarding reducing code duplication and improving code readability, however as it is a completely new technology C++ compilers and build systems haven't caught up too much with the technology yet. So atm clang-16 is the minimum requirement, as well as CMake 3.26 with experimental flags enabled. This means the production compilation relies on unstable tools, which results in the current compilation issues.
To address this issue, we have several options:
Still even with the above potentional suolutions there might be some trouble with compilation (e.g. if the libc++ does not match), so this area still needs a lot of rework to get more stable.
5.2 The problem with dynamic plugins that require code to be executed
As of now FlorisBoard supports extensions for stuff like themes, keyboards, etc. which works really well. However there are things that require more advanced tooling/flexibility, features like word suggestion, voice transcription etc. come to mind first. These type of features often require custom logic which cannot be represented in a static JSON-file, thus we need a more advanced system. One idea would be to have "plugin APKs" for these cases, where you installl FllorisBoard as a core app and the plugin you want to use as another app, then those two communicate with each other. This requires the usage of Android services however, which are not fast and require a stablel binary messaging protocol format to be used.
5.3 Issues regarding the existing extension JSON code base
Some additional issues noticed revolve around the logic (and frontend UI) regarding importing/exporting extension files, as we both have no clear UI/UX concept and spaghetti code. This area definitely needs a rework within the next 2-3 major versions, however atm it is not directly assigned to a milestone.
5.4 Other issues regarding the code structure
During the last big review of the Kotlin-side of the code base a lot of issues came to mind regarding separation of features and abstraction. In its current state there have been a lot of band-aid fixes applied to the rather old text logic and keyboard layout engine, which has resulted in quite some bugs that are almost impossible to iron out without introducing two others. As such the text processing logic and the keyboard layout engine will see a full rewrite in 0.5. This does not affect the theme engine however and the new keyboard layout engine will use the existing Snygg themeing logic.
Beta Was this translation helpful? Give feedback.
All reactions