que faire avec ça et figma ?
Pour le moment rien on bosse dessus avec Boris et un collègue à lui qui fait les dessin de lezards.
Quand on sera satisfait, on vous présentera le player qui vous permettra de naviguer dans l’app.
A ce moment là vos retours d’UX seront précieux.
Une fois l’UX validé, je l’implémente en Flutter.
Bon Xcode en place sur le Mac, Flutter aussi mais là je ne sais pas quoi faire car ce que j’ai ne correspond pas aux écrans. Ainsi que LLVM.
On continue en privé sur forum monnaie libre ?
Car si tu arrives à lancer un helloworld Flutter sur Mac, il va falloir que je t’explique comment installer les dépendances pour compiler la partie Rust, et LLVM en fait partie en effet.
On va devoir s’appeler et beaucoup échanger pour arriver à ce que tu compile Gecko pour iOS, et c’est très spécifique, alors autant le faire en privé 
Après avoir annoncé il y a quelques jours que le futur installateur d’Ubuntu 22.04 serait conçu en Flutter, c’est en réalité un vrai tournant que va prendre Canonical, la société éditrice d’Ubuntu. Les nouvelles applications conçues par la société seront désormais faites en Flutter, qu’il s’agisse des applications Linux ou pour smartphones. Une vraie révolution !
Le projet est très intéressant et ambitieux. J’y vois néanmoins quelques défauts :
- Imite les widgets natifs, mais ne les utilisent pas, ce qui fait que certaines interfaces sont « dans la vallée de l’étrange » ou/et plus lente que le natif).
- Il manque des bindings pour d’autres langages que Dart (Python ? ).
- Le style dessin animé Mobile avec animation, pas toujours pertinent pour le Desktop (mais en ce moment c’est ça ou une interface digne d’un formulaire excel des années 90…)
Si le projet n’est pas rentable, il risque (ce que je ne souhaite pas) de finir au cimetière des projets Google…
Pour Gecko, quel est le langage qui s’occupe de la logique et celui qui s’occupe de l’UI ? Est-ce Dart pour les deux ? Flutter est un framework en Dart, pas une simple bibliothèque Dart, c’est ça ?
Si en fait sur Android/iOS Flutter compile en C toute l’UI pour utiliser les widgets purement natifs. Ce qui est ajouté en plus d’une app native, c’est la VM Dart pour la partie logique.
Les widgets sont donc des widgets purement natifs.
Je ne comprends pas ce que tu veux dire. Flutter a été conçus pour Dart, toute app Flutter se code en Dart uniquement.
Si tu veux dire utiliser python dans une app flutter, ce doit être possible grâce à ffi comme tout language, je suppose, ya pas mal de littératures à ce sujet mais je n’ai pas creusé encore cette voix
Bah je trouve justement que ça permet de faire des UI modernes qui passent partout, tu peux adapter l’UI pour desktop, et ils semblent avoir pas mal bossé sur l’intégration web et desktop, à tester.
Très franchement, ya très peu de chance pour que Flutter soit abandonné comme ça, parceque ya plus que Google dessus, regarde les partenaires: Microsoft avec leur surface, Ubuntu veulent utiliser Flutter pour toutes les futures app natives ! Et tant d’autres … Tout ces acteurs ont et vont contribuer à Flutter.
Gecko c’est du Flutter, donc Dart pour la logique, Dart est un SDK en plus d’être un language, ça a sa nuance. Flutter est également un SDK, qui utilise le SDK Dart, ça fait donc 2 SDK.
La partie logique est donc Dart + Rust pour la crypto.
Si on pousse le vice à l’extrême, on peut très bien imaginer faire toute la logique de Gecko en Rust exclusivement, Dart ne servant alors que d’interface pour le binding ffi.
Mais bon je n’y vois pas trop l’intéret, d’autant que c’est pas moi qui irai coder toute ma logique en Rust lol.
Donc avec cette même logique, avec un binding ffi python pour Dart, tu dois pouvoir faire toute la logique en python dans une app Flutter.
Mais honnêtemet, passer de python à Dart c’est finger in the noze, regarde c’est ce que j’ai fait.
Le plus compliqué c’est pas la partie Dart, Dart est hyper simple (et bien plus performant que python, j’ai testé de refaire un début de jaklis en pure dart ligne de commande, je passe de ~350ms à ~20ms d’execution…), c’est surtout le maniement des widgets flutter, et la gestion de leurs états. Ca c’est du pure flutter (surchargeant Dart).
Concernant python bindé avec ffi pour Dart, je spécule, en vrai j’en sais rien, Python est un language interprété, non compilé, incomparable à Rust ou Dart, donc vraiment j’en sais rien, à creuser/tester.
@vit regarde par exemple ce fichier, c’est le model pour la vue historique des transcations:
On dirait pas du python niveau syntaxe en vrai ?
Bon je viens de tester Flutter web pour la première fois.
Pour Gecko, la difficulté va être de builder la partie Rust pour la bonne architecture, sans quoi impossible de faire fonctionner Gecko en web (en fait c’est surtout ffi qui n’est pas pris en charge pour le web, les appels natifs ne fonctionne pas dans les technos web, je ne sais pas si c’est prévu de prendre ça en charge à l’avenir par l’équipe de Flutter, ni même si c’est techniquement faisable).
Cependant, j’ai voulu essayer avec l’une des toute première version de gecko, au tout début (nostalgie, de ya 3 mois…).
J’ai donc checkout un vieux commit, je n’ai absolument rien touché au code, et voici (gif):
Et toujours pour le fun, le voilà accessible à tous hébergé sur une de mes VM:
https://gecko-oldschool.p2p.legal/
(Je crois que ça en fait le premier « client » GVA web non ? lol)
Malheureusement à cause du binding Rust par ffi, je pense qu’on est pas prêt de voir Gecko en web… Par contre pour Desktop oui là ça peut.
En fait ce n’est pas une question d’architecture, le problème est tout autre : l’environnement web est particulier, il ne peut s’y exécuter que du javascript ou du webassembly, car le navigateur ne sait exécuter que ça.
Flutter web fonctionne en réalité via une transpilation du Dart en Javascript (comme pour Typescript finalement).
Rust peut être compilé en webassembly, du binaire pouvant être chargé et exécuté depuis du javascript.
Il « suffirait » donc d’ajouter au code javascript issue de la transpilation, les bons appel javascript pour charger et utiliser un binaire .wasm, et de fournir ce binaire .wasm dans les assets.
En théorie c’est donc possible, en pratique certains semblent l’avoir fait :
Un bel article de comparaison avec l’approche d’Ionic, qui choisi d’utiliser les standards web (HTML, CSS, TS/JS) plutot que du code base maison (Flutter, Dart).
En faisant une App Ionic, on n’est finalement peut dépendant d’Ionic, et on reste dans le mode des standards web (les plus testés et évolutifs de tous les temps).
Je me tatais pour Cesium2, mais c’est tout vu : “je reste” sur du Ionic 
Oui c’est ce que je me disais, toi qui maitrise Ionic ce serait contre productif que du te mettre à Dart.
Moi ce n’était juste pas mon cas.
Cependant ton article n’est pas daté (dans le sens il n’y a pas la date de publication), et il s’agit du blog officiel de Ionic qui en fait la promotion (les perf flutter web ne sont pas “mauvaise” par exemple, en tt cas plus maintenant, et à savoir que le but premier de Dart en 2012 était de remplacer javascript comme standart web, ce qui a été un échec total à ce niveau de la part de google…).
Je préfère cet article daté et indépendant par exemple: Ionic Vs Flutter Which Is The Best For You - Hidden Brains Blog
Même si en vrai les conclusions sont assez proche de l’article d’ionic, il y a quand même quelques précisions.
Et pourtant le constat est sans équivoque :
Disadvantages of Ionic
- Not suitable for high performance or UI intensive apps
- Not meant for game development
Disadvantages of Flutter
- Need to learn Dart
- Lack of community support
- Lack of promotion
- Lack of friendly documentation
Les inconvénients de flutter sont uniquement liés à sa jeunesse, ils sont déjà de moins en moins vrais et ne seront même plus vrai du tout d’ici quelques années.
Alors que les inconvénients de Ionic sont structurels.
Il n’y a que les perfs, mais je les connais déjà bien 
car l’autre inconvénient porte sur les jeux !
Ce problème « structurel » et par ailleurs liées à l’usage des standards web (CSS notamment), mais qui tend à toujours être plus rapide y compris sur mobile. Il faut coder en pensant que la puissance des terminaux et des navigateurs augmente sans cesse. C’est l’avantage des standards que de profiter de recherche continue d’optimisation.
Il n’y a pas de solution qui convienne à tout. C’est un compromis. Moi j’ai choisi mais c’est très bien je trouve que cela se complète avec d’autres apps.
Par ailleurs, le problème des perfs disparaît sur les versions PC. Là encore du fait de l’optimisation des navigateurs et de la puissance de calcul.
Bon après moi, Ionic où Flutter, les deux j’en fais pas 
Disons qu’en terme le langage, je préfère le Dart au Javascript/Typescript, y a ça qui joue aussi, mais je préfère le Rust au Dart, donc si un jour j’ai besoin de faire une interface graphique, j’utiliserai un framework Rust
Merci pour le low tech 
Voilà comment on se retrouve avec un éditeur de texte qui prend 200 Mo de RAM.
Franchement je préfère un langage compilé avec des perfs correctes qui permet de garder un vieux téléphone .
Penses tu que le couple Dart + Flutter prenne en charge de vieux téléphones Android ? As tu vérifié ce point ? Perso, je n’en sais rien. Le fait d’être compilé n’a rien à voir avec le support, simplement avec les performances.
Ce que je sais, en revanche, c’est que HTML + CSS + JS fonctionne sur des vieux téléphones, même si c’est parfois lent.
Par exemple, Cesium peut se compiler pour de vielles version d’Android. J’allais justement le faire, en réponse à @Candidesk8 (cf ce fil) qui aimerai une version fonctionnelle sur Android 4.2.2
Oui à partir de Android 4.2 en fait (2011)
par contre pour les version antérieur ce n’est pas prévus.
Le pbm de Candide est tout autre 
Il s’agit d’un soucis avec le FairPhone 1 en particulier, avec le binding rust, il ne fait pas le lien alors qu’il devrait. Mais on va finir pas trouver l’origine de ce bug.