Gui framework decision #89

Closed
opened 2024-05-03 13:22:18 +02:00 by PatrykHegenberg · 4 comments
PatrykHegenberg commented 2024-05-03 13:22:18 +02:00 (Migrated from github.com)

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.

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.
PatrykHegenberg commented 2024-05-08 06:56:55 +02:00 (Migrated from github.com)

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 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.
ikeen0807 commented 2024-05-10 10:34:12 +02:00 (Migrated from github.com)

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.

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.
PatrykHegenberg commented 2024-05-28 06:58:11 +02:00 (Migrated from github.com)

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.

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.
PatrykHegenberg commented 2024-05-29 06:37:04 +02:00 (Migrated from github.com)

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.

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.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: git/caesar-transfer#89
No description provided.