Sortie de Kivy 1.0.7 - Framework pour des applications multitouches

Posté par  (site web personnel) . Modéré par patrick_g.
Étiquettes :
30
18
juil.
2011
Python

Kivy est un framework complet pour la création d'interfaces nouvelles comme des applications multitouches. Développé en Python/Cython/OpenGL ES 2 et sous licence LGPL, ce framework a la capacité de tourner sur Windows, MacOSX, Linux, Android (iOS en développement).

Cette version 1.0.7 intègre une gestion de configuration d'application, les outils nécessaires pour faire un paquet sous les différentes plateformes, et des performances accrues grâce à une gestion optimisée des textures.

Par ailleurs, l'équipe de Kivy a développé PreseMT, un outil permettant la création de présentation. Cet outil consiste à mettre des images et du texte sur un plan infini, puis d'enregistrer des vues de ce plan comme des vignettes.

Kivy est modulaire et découpé en plusieurs parties.

Core providers

Au lieu d'utiliser une bibliothèque précise pour la lecture d'image, de vidéos… Kivy a une approche abstraite. Chaque fonctionnalité est implémentée une ou plusieurs fois en utilisant diverses bibliothèques. Ce qui permet au framework d'utiliser la meilleure implémentation selon la plateforme ou le système courant.
Par exemple, le chargement d'image peut se faire avec Pygame, PIL, la lecture de la caméra peut se faire avec OpenCV, GStreamer, VideoCapture, etc.

Inputs

La gestion des inputs est toujours problématique tant par la diversité de ceux-ci et par les multiples approches possibles. Kivy a opté pour une structure de données unique quelle que soit l'entrée: souris, tablette, stylet, fiducials, kinect, accéléromètre, etc.

Cette structure, nommée MotionEvent, est générée par un ou plusieurs "Input Providers", qui sont automatiquement créés par Kivy selon la plateforme. À ce jour, Kivy gère nativement les évènements multitouches WM_Touch, WM_Pen de Windows, MTDev, HIDInput et LinuxWacom sous Linux (selon noyau et disponibilité), MacOSX, Android, ainsi que TUIO.

Ensuite, cette structure est envoyée dans l'arbre des widgets par 3 événements uniques: on_touch_down, on_touch_move, on_touch_up, si le MotionEvent contient au minimum une information de position 2D. Sinon, ce n'est pas considéré comme une touch. Il est toujours possible de s'inscrire à la fenêtre et de récupérer tous les évènements d'entrées.

À noter que Kivy intègre un simulateur multitouch avec la souris : le bouton droit permet de laisser une touche à l'écran, indiquée par un rond rouge.

Graphics

Un moteur graphique optimisé pour l'affichage 2D est basé sur OpenGL ES 2. Cette version est celle que l'on retrouve en grande majorité dans les mobiles et utilise une manière moderne de faire du rendu graphique. En se restreignant à ces instructions, Kivy est capable de faire son rendu sur les ordinateurs de bureaux ou les mobiles.

Kivy implémente par défaut plusieurs instructions pour changer la couleur, tracer des rectangle, ellipse… en utilisant une texture ou non. Un point intéressant est son compilateur d'instructions à la volée qui permet, après analyse, de réduire le nombre d'instructions graphiques à envoyer au GPU à son minimum. Cette partie est encore en cours de développement, mais le but serait de pouvoir de combiner les instructions entre elles dans la mesure du possible.

Widgets

Plus de 20 widgets sont disponibles, utilisant les couches décrites ci-dessus. La base d'un Widget est basée sur des évènements, et liée à des instructions graphiques. Lorsque l'on change une propriété du widget, celui-ci mettra à jour sa représentation graphique, et déclenchera un nouvel affichage.
Un langage nommé Kv a été créé afin de permettre de créer rapidement une représentation graphique d'un widget, ainsi que de créer des interactions. Ce langage s'apparente à QML de Qt, ou encore à la CSS pour HTML.

Aller plus loin

  • # Multitouche?

    Posté par  . Évalué à 10.

    Je m'en veux de jouer le pinailleur de service, mais je trouve que "multitouche" est une traduction quelque peu malheureuse. Quelque chose comme "tactile multi-point" serait plus clair, amha. À moins que je n'aie manqué une nouvelle saillie de nos chers académiciens?

    • [^] # Re: Multitouche?

      Posté par  (site web personnel, Mastodon) . Évalué à 0.

      Tout à fait d'accord (et pour pinailler aussi, "multi-touches" serait à mon avis plus approprié que "multitouches", même si cette traduction est effectivement hasardeuse).

      WeeChat, the extensible chat client

    • [^] # Re: Multitouche?

      Posté par  . Évalué à 2.

      Je ne pense pas que ça vienne de nos académiciens, ils ont plus d'imagination que ça et il en faut pour traduire « chat » en « éblabla ». Ils ne se contenteraient pas d'un vulgaire « multitouche » trop proche de l'original.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Multitouche?

        Posté par  . Évalué à 1.

        Oui, enfin ils ont bien commis "mél"…

        C'est surtout qu'ici "multitouche" n'est pas cohérent avec les différents sens du mot "touche": le mot auquel il fait réellement référence est "toucher". En anglais "touch" est à la fois un verbe et un nom désignant l'action correspondante. En français le mot "touche", qui est bien dérivé de "toucher", ne signifie pas "action de toucher".

        • [^] # Re: Multitouche?

          Posté par  . Évalué à -1.

          Extrait du tlfi :

          TOUCHE, subst. fém.

          I. − Action, manière de toucher.
          …

          • [^] # Re: Multitouche?

            Posté par  . Évalué à 2.

            Sauf que tu ne cites que le début de la définition.

            "touche" ne désigne l'action de toucher que pour quelques sens très spécifiques: en escrime, en religion (au figuré), et quelques autres utilisations en vieux français.

            En aucun cas, "touche" n'est une traduction de "touch" en anglais. En aucun cas il ne peut servir à désigner l'action de poser un doigt sur un écran - ce qui est le sujet, ici.

        • [^] # Re: Multitouche?

          Posté par  (site web personnel) . Évalué à 2.

          mél. est uniquement un symbole, comme tél., pas un substantif :)
          source: http://www.academie-francaise.fr/langue/questions.html#courriel

    • [^] # Re: Multitouche?

      Posté par  . Évalué à 1.

      Ce n'est pas simplement le pluriel de multitouch (en anglais) ?

      • [^] # Re: Multitouche?

        Posté par  . Évalué à 1.

        Intéressant. En anglais, "multitouch" ne s'accorde pas (dans "multitouch applications"). Mais il est possible que l'accord soit obligatoire si on emprunte le mot dans une phrase en français… Quelqu'un pour confirmer?

  • # Présentation aux RMLL

    Posté par  . Évalué à 6.

    Il y a eu une présentation aux RMLL cette année sur Kivy.

    Et il faut dire que c'est assez impressionnant !

  • # Kivy / Processing

    Posté par  . Évalué à 5.

    Bonjour,

    Comment se positionne ce framework par rapport à un outil complet comme Processing par exemple ? Est-ce qu'on produit au final des choses similaires ou est-ce que cela n'a complètement rien à voir ? Car dans les dernières versions de Processing, on peut produire aussi pour Android et gérer les écrans tactiles.

    Est-ce qu'on doit le comparer davantage à QtQuick par exemple, car je vois des similarités entre le QML et le langage kv ?

    http://kivy.org
    http://processing.org
    http://qt.nokia.com/qtquick

    Merci pour vos réponses et points de vue.

    • [^] # Re: Kivy / Processing

      Posté par  (site web personnel) . É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.

      • [^] # Re: Kivy / Processing

        Posté par  . É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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.