Gui framework decision #89
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: git/caesar-transfer#89
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In order to be able to use only one framework for all the planned platforms and to implement everything in Rust, we opted for Dioxus as the GUI framework.
If there are any suggestions or comments on this topic, these can be recorded here until the start of implementation.
We should have a final discussion about the GUI framework this week.
I've already played around a bit and tried out slint, egui and tauri2.0 beta in addition to dioxus.
In fact, I'm not at all convinced by dioxus, as the api there is very unstable and there are massive changes between versions.
In #90 would be a simple design for the sending GUI, which is also built with dioxus.
However, I have to say that this is very unstable and sometimes does not correspond to the described design for no apparent reason.
We discussed GUI frameworks and we decided to test 2 frameworks for prototypical implementation, where we experience how the framework behaves and how it performs in mobile and desktop. Patryk will cover the Flutter part and Kryztstof and I will be covering the Tauri 2.0 part. I will concentrate on the implementation via Tauri 2.0 in combination with Angular as Web Framework. Kryzstof will focus on implementing Tauri 2.0 with raw JavaScript, HTML and CSS. Therefore we are going to have a certain decision by the half of next sprint. Either it will be Tauri 2.0 or Flutter.
Since we have not yet made a final decision on a framework, we should make the decision after the feature freeze on May 28th based on the status of the candidates.
Based on a small A/B test and an extensive round of discussions, we initially opted for the Flutter version of the front end.
The reason for this is that the ecosystem is more mature and the variant is more feature-complete than the Tauri variant.
We will therefore use Flutter for the beta release.
In the long term, however, the Flutter version will replace the Tauri version, as it offers a better and more intuitive connection between the frontend and backend in Rust and is more developer-friendly for our team.