Moi aussi, un langage descriptif de l'interface (type QML) ça me botte.
Jusqu'à ce que l'on réalise qu'il n'est pas dynamique, il faut le compiler sur l'hôte pour que ça donne l'UI (contrairement à QtQuick/QML).
Du coup, pour moi, ça perd pas mal d'intérêt.
Pourquoi ne pas faire un éditeur graphique (c'est quand même beaucoup plus simple à utiliser) s'il faut compiler de toutes façons ?
Là où ça aurait vraiment été super classe, c'est une description de l'UI (en JSON, ou même comme ils ont fait), que l'on peut changer au runtime, avec un lien entre les widgets et les signaux générés (et gérés dans le code compilé, lui). Histoire de pouvoir, par exemple, modifier le fichier, l'uploader sur la cible et zou le nouvel UI apparaît.
Sur un processeur embarqué, c'est gagner un temps fou de développement, car il suffit simplement d'avoir un système de fichier et un serveur web (très simple sur ESP32, Pi et autre) au lieu d'avoir à générer un binaire monstrueux, faire un OTA et attendre que ça reboote pour voir le résultat.
Après, il y a la solution demo "web", c'est pas mal, mais moins pratique qu'un éditeur graphique au final.
J'ai aussi un peu de mal avec le rust et l'embarqué, le support de rust dans l'embarqué, c'est quand même pas trop top en ce moment, mais ça s'améliore... C'est surtout le manque de bibliothèques qui m'empêche d'utiliser rust et si le système en dépend, ça fait un langage de programmation en plus à gérer dans la chaîne de compilation déjà complexe d'un projet embarqué.
[^] # Re: Ce n'est pas du natif
Posté par xryl669 . En réponse à la dépêche Slint 1.0 : une boîte à outils graphiques natifs pour poste client et embarqué. Évalué à 2.
Moi aussi, un langage descriptif de l'interface (type QML) ça me botte.
Jusqu'à ce que l'on réalise qu'il n'est pas dynamique, il faut le compiler sur l'hôte pour que ça donne l'UI (contrairement à QtQuick/QML).
Du coup, pour moi, ça perd pas mal d'intérêt.
Pourquoi ne pas faire un éditeur graphique (c'est quand même beaucoup plus simple à utiliser) s'il faut compiler de toutes façons ?
Là où ça aurait vraiment été super classe, c'est une description de l'UI (en JSON, ou même comme ils ont fait), que l'on peut changer au runtime, avec un lien entre les widgets et les signaux générés (et gérés dans le code compilé, lui). Histoire de pouvoir, par exemple, modifier le fichier, l'uploader sur la cible et zou le nouvel UI apparaît.
Sur un processeur embarqué, c'est gagner un temps fou de développement, car il suffit simplement d'avoir un système de fichier et un serveur web (très simple sur ESP32, Pi et autre) au lieu d'avoir à générer un binaire monstrueux, faire un OTA et attendre que ça reboote pour voir le résultat.
Après, il y a la solution demo "web", c'est pas mal, mais moins pratique qu'un éditeur graphique au final.
J'ai aussi un peu de mal avec le rust et l'embarqué, le support de rust dans l'embarqué, c'est quand même pas trop top en ce moment, mais ça s'améliore... C'est surtout le manque de bibliothèques qui m'empêche d'utiliser rust et si le système en dépend, ça fait un langage de programmation en plus à gérer dans la chaîne de compilation déjà complexe d'un projet embarqué.