J'ai parcouru davantage la documentation Kivy et fait quelques essais.
Par rapport à Processing, il est vrai qu'ils n'ont pas la même finalité. L'avantage de Kivy est tout le processus industriel autour : un vrai framework, une vraie documentation, des outils de gestion des fichiers log, des outils de gestion des configurations, des outils de déploiement et une abstraction intuitive même dans la syntaxe de création des objets. J'aime aussi la possibilité d'évaluer des expressions Python directement dans le langage kv, très pratique. Je pense que Kivy ne demande qu'à s'enrichir en terme de fonctionnalités. On peut déjà néanmoins y inclure presque n'importe quelle librairie Python disponible (importer des données Sqlite, générer des flux RSS avec feedparser et afficher dans une scrollview).
Par rapport à Qt/QtQuick, je trouve la gestion des échanges entre les vues et les contrôleurs beaucoup plus intuitive et simple que les échanges à la Qt, même si cela y ressemble fortement. Pour avoir fait quelques tests avec PySide et QtQuick, j'ai toujours trouvé et la documentation et la logique trop calquée sur une logique C++ qu'une logique Python pour des raisons techniques et historiques connues. Si l'on trouve énormément de documentation Qt / QtQuick pour C++, l'on en trouve moins pour Python. De plus l'implémentation Qt / QtQuick est peu documentée. Les QtAbstract ne sont pas évidentes à implémenter en Python et QtQuick par exemple lorsqu'on doit gérer des scrollview avec des lignes constituées de plusieurs champs différents provenant d'une base de données. Les modèles abstraits sont complexes à mettre en place. Je trouve la logique de Kivy plus orientée Python et finalement plus claire. En terme de performance, QtQuick rame pas mal sur des smartphones (ARM 800 MHz par exemple).
Bref j'ai un sentiment positif et de fraîcheur après m'être documenté sur Kivy et son approche.
P.S : je vous ai en fait découvert en cherchant une vieille bibliothèque graphique PyUI (http://pyui.sourceforge.net/) qui utilisait également OpenGL pour le rendu.
[^] # Re: Kivy / Processing
Posté par highleaf . En réponse à la dépêche Sortie de Kivy 1.0.7 - Framework pour des applications multitouches. Évalué à 4.
Je vous remercie pour vos éclaircissements.
J'ai parcouru davantage la documentation Kivy et fait quelques essais.
Par rapport à Processing, il est vrai qu'ils n'ont pas la même finalité. L'avantage de Kivy est tout le processus industriel autour : un vrai framework, une vraie documentation, des outils de gestion des fichiers log, des outils de gestion des configurations, des outils de déploiement et une abstraction intuitive même dans la syntaxe de création des objets. J'aime aussi la possibilité d'évaluer des expressions Python directement dans le langage kv, très pratique. Je pense que Kivy ne demande qu'à s'enrichir en terme de fonctionnalités. On peut déjà néanmoins y inclure presque n'importe quelle librairie Python disponible (importer des données Sqlite, générer des flux RSS avec feedparser et afficher dans une scrollview).
Par rapport à Qt/QtQuick, je trouve la gestion des échanges entre les vues et les contrôleurs beaucoup plus intuitive et simple que les échanges à la Qt, même si cela y ressemble fortement. Pour avoir fait quelques tests avec PySide et QtQuick, j'ai toujours trouvé et la documentation et la logique trop calquée sur une logique C++ qu'une logique Python pour des raisons techniques et historiques connues. Si l'on trouve énormément de documentation Qt / QtQuick pour C++, l'on en trouve moins pour Python. De plus l'implémentation Qt / QtQuick est peu documentée. Les QtAbstract ne sont pas évidentes à implémenter en Python et QtQuick par exemple lorsqu'on doit gérer des scrollview avec des lignes constituées de plusieurs champs différents provenant d'une base de données. Les modèles abstraits sont complexes à mettre en place. Je trouve la logique de Kivy plus orientée Python et finalement plus claire. En terme de performance, QtQuick rame pas mal sur des smartphones (ARM 800 MHz par exemple).
Bref j'ai un sentiment positif et de fraîcheur après m'être documenté sur Kivy et son approche.
P.S : je vous ai en fait découvert en cherchant une vieille bibliothèque graphique PyUI (http://pyui.sourceforge.net/) qui utilisait également OpenGL pour le rendu.
Bonne continuation.