Ce n'est pas vraiment le même type de librarie. Dans Processing, tu n'as pas de hiérarchie ou de widgets. Si je ne me trompe pas, tu fais un peu tout à partir d'une fonction draw() et c'est tout. A toi de gérer la souris ou le "tactile multi-point" comme tu veux.
On rajoute une couche de Widget et une gestion uniforme des entrées en quelques sortes. Mais cela ne remplace pas Processing. Il est plus facile de faire quelque chose d'artistique sur un ce dernier, car la logique est plus commune: tu dis ce que tu veux tracer pour chaque image. De notre coté, tu dois préparer tes instructions.
Pour ce qui est de QML, le langage Kv est très proche dans la logique. QML a été un peu comme un coup de foudre pour nous pour son approche. Mais nous ne voulions pas l'utiliser, et rester proche de Python. Et nous voulions aller plus loin, comme créer des templates, des règles à la CSS etc.
[^] # Re: Kivy / Processing
Posté par tito (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Kivy 1.0.7 - Framework pour des applications multitouches. Évalué à 3.
Ce n'est pas vraiment le même type de librarie. Dans Processing, tu n'as pas de hiérarchie ou de widgets. Si je ne me trompe pas, tu fais un peu tout à partir d'une fonction draw() et c'est tout. A toi de gérer la souris ou le "tactile multi-point" comme tu veux.
On rajoute une couche de Widget et une gestion uniforme des entrées en quelques sortes. Mais cela ne remplace pas Processing. Il est plus facile de faire quelque chose d'artistique sur un ce dernier, car la logique est plus commune: tu dis ce que tu veux tracer pour chaque image. De notre coté, tu dois préparer tes instructions.
Pour ce qui est de QML, le langage Kv est très proche dans la logique. QML a été un peu comme un coup de foudre pour nous pour son approche. Mais nous ne voulions pas l'utiliser, et rester proche de Python. Et nous voulions aller plus loin, comme créer des templates, des règles à la CSS etc.