Kivy est un cadriciel (framework) graphique, permettant de développer des interfaces tactiles (ou utilisable à la souris) sur toutes les plateformes, y compris mobiles. Il s'accompagne d'une suite de logiciels très pratiques que nous allons présenter ici.

Sommaire

• Kivy : boîte à outils graphique multi-plateformes
• kv : interface graphique en déclaratif
  • Les propriétés
• Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil
• Python For Android : utiliser Python… sur Android
• Kivy for iOS : déployez sur les appareils Apple
• Pyjnius : utiliser l’API Java Android depuis Python
• KivyMD, des widgets Material Design
• Quelques limitations
• Conclusion
• Une note d’histoire

Kivy : boîte à outils graphique multi-plateformes

Kivy permet de créer des interfaces graphiques naturellement adaptées aux écrans tactiles (mais qui restent utilisables sur un environnement de bureau traditionnel, à la souris et sans écran tactile). Il est écrit principalement en Python mais les parties critiques sont écrites en Cython, ce qui lui permet d’avoir de bonnes performances.

Une interface Kivy peut s’écrire de deux façons (ou, plus couramment, par une combinaison de ces deux façons) : en Python directement, ou via kv, une syntaxe déclarative dont nous parlons plus bas.

Pour vous donner une idée, voici un exemple de hello world repris du site officiel de Kivy :

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Ce qui donnera :

Une interface est composée de « widgets » agencés via des « layouts ». Certains widgets permettent de facilement mettre en place des composants communs de nos jours, comme par exemple le widget Carousel :

D’autre part, Kivy fournit des outils qui simplifient la vie du développeur ou de la développeuse, en particulier un système de propriétés (à ne pas confondre avec les propriétés Python) qui permet de mettre automatiquement l’interface à jour quand elles sont modifiées, ou de facilement attacher une fonction de rappel (« callback »), voir plus bas pour un exemple simple. On peut aussi citer un mécanisme d’animations très pratique et efficace.

kv : interface graphique en déclaratif

kv est un langage permettant de décrire des interfaces, il met à profit les propriétés mentionnées plus haut et l’interface va se mettre à jour automatiquement quand des propriétés utilisées dans kv sont modifiées.

Reprenons le hello world vu plus haut, et faisons-le avec kv:

Widget:
    Button:
        text: "Hello World"

Plutôt simple non ?
Le code kv est généralement mis dans des fichiers séparés avec l’extension .kv.

Les propriétés

Kivy a donc un concept de propriété, qui permettent la liaison de données bidirectionnelles (two-way data binding), ou en d’autres termes de facilement avoir l’état mis à jour entre le code python et l’interface décrite dans le fichier kv. C’est à l’usage très pratique et facile.

Un exemple va sans doute aider à comprendre.

Commençons par faire un environnement virtuel Python avec Kivy:

$ mkdir demo

$ cd demo

$ python -m venv env

$ source env/bin/activate

$ pip install kivy

Ensuite créez le fichier demo.py suivant :

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.properties import NumericProperty

class CompteurWidget(BoxLayout):
    compteur = NumericProperty(0)

    def increment(self):
        self.compteur += 1

class DemoApp(App):
    def build(self):
        return CompteurWidget()

DemoApp().run()

Et maintenant, dans le même répertoire, ajoutez le fichier demo.kv suivant, ce dernier sera automatiquement découvert par Kivy parce qu’il s’appelle comme notre application (DemoApp) sans le suffixe App et en minuscule :

<CompteurWidget>:
    orientation: 'vertical'
    padding: 20

    Label:
        text: str(root.compteur)
        font_size: 30

    Button:
        text: "Incrémenter"
        on_press: root.increment()

Il ne nous reste plus qu’à lancer le programme :

python demo.py

Et à admirer :

Le label se met automatiquement à jour quand le compteur compteur est incrémenté.

La lectrice ou le lecteur assidu de DLFP pourra faire un TapTempo en exercice.

Note: Ne vous arrêtez pas au fait que l’UI est un peu "moche" par défaut, il y a des extensions beaucoup plus attractives (cf. KivyMD plus bas), et il est très facile de personnaliser l’interface et d’en faire une très belle en modifiant un peu ses fichiers .kv.

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Plyer est une bibliothèque permettant d’accéder à nombre de fonctions utiles de manière indépendante de la plateforme. Ainsi vous avez une API commune pour afficher une notification, demander l’état de la batterie, faire vibrer l’appareil, faire de la synthèse vocale de texte (« text-to-speech »), ouvrir un fichier avec le dialogue natif de la plateforme, etc.

Bien que développé par la même équipe que Kivy, ce paquet est utilisable indépendamment et est donc particulièrement utile pour n’importe quel projet multi-plateformes. Référez-vous à la page du projet pour avoir un tableau des fonctionnalités supportées selon les plateformes, et à la documentation pour plus de détails.

Python For Android : utiliser Python… sur Android

Si vous souhaitez distribuer votre application sur Android, vous allez devoir avoir une version de Python compilée pour cette plateforme, ainsi que de tous les paquets nécessitant une compilation.

C’est le rôle de Python pour Android, qui est une collection d’outils qui s’appuient sur l’Android SDK pour permettre d’utiliser Kivy ou d’autre paquets Python sur Android, et ainsi faire votre propre distribution Python.

Si vous utilisez un paquet qui n’est pas en pur Python (c’est-à-dire qu’il y a des parties à compiler) et qui n’est pas encore disponible ou qui l’est mais dans une version trop ancienne, vous pouvez écrire ou mettre à jour des « recettes » (recipes en anglais) qui indiquent comment compiler. Référez-vous à la documentation pour voir comment faire.

Notez toutefois qu’il y a une pénalité à utiliser du Python par rapport à une application dans un langage compilé : il faut charger l’interprète au démarrage, et au tout premier lancement de votre application (et uniquement au premier) il y a aura une phase de décompression de vos fichiers. En dehors de ces petits inconvénients, ça fonctionne très bien.

Là encore, le projet est indépendant de Kivy et peut être utilisé avec un autre cadriciel.

Kivy for iOS : déployez sur les appareils Apple

À l’instar d’Android, l’équipe de Kivy fournit les outils pour faire votre distribution Python pour iOS.

Il vous faudra posséder une machine Apple pour les utiliser, à cause des restrictions imposées par cette plateforme (ceci n’est pas spécifique à Kivy pour iOS, mais s’applique à tous les outils pour développer sur iOS).

Ainsi avec une seule base de code (et après avoir passé un peu de temps pour configurer correctement les outils de compilation), vous pouvez déployer votre application Kivy/Python sur toutes les plateformes majeures (hormis le web, pour lequel il existe d’autres options comme Brython, Pyodide ou PyScript, mais c’est un sujet pour une autre dépêche).

Pyjnius : utiliser l’API Java Android depuis Python

Parfois l’utilisation de Plyer mentionné plus haut et de la bibliothèque standard Python ne suffisent pas, et vous avez besoin d’accéder à l’API d’Android, mais cette dernière est faite pour être utilisée avec Java ou Kotlin.

Pour pouvoir utiliser l’API d’Android depuis Python, PyJNIus est disponible. Ce paquet permet d’accéder aux classes Java comme à des classes Python en utilisant JNI (« Java Native Interface » ou « Interface Native de Java »).

Ce paquet fournit une méthode autoclass qui convertit automatiquement une classe Java en Python, c’est très facile à utiliser et souvent suffisant pour les cas simples.

KivyMD, des widgets Material Design

KivyMD n’est pas un projet officiel de l’équipe Kivy, mais un projet tiers dédié à la création d’un ensemble de Widgets thémables adoptant Material Design.

L'image ci-dessus est issue de la documentation de KivyMD, vous trouverez également des démos vidéo sur le dépôt du projet.

Quelques limitations

Une petite note sur mon expérience personnelle (Goffi). Kivy est un excellent cadriciel, et l’équipe est accueillante et réactive : c’est un projet que je recommanderais en général. Ceci dit, dans mon cas particulier (un client XMPP ayant de nombreuses fonctionnalités), j’ai quelques limitations qui me poussent actuellement à chercher des alternatives, notamment basées sur Qt (PyQt et PySide) :

• l’accessibilité est un problème majeur. L’équipe y travaille, mais aujourd’hui les applications Kivy ne sont pas accessibles. C’est notamment dû au fait que l’interface utilisateur est entièrement gérée par Kivy, au lieu d’utiliser des composants natifs, et c’est un point complètement bloquant pour moi.
• il n’y a pas de webview ou de rendu HTML natif, ce qui est bloquant parce que je fais du rendu de blogs.
• le rendu de texte est incomplet, notamment sur les plateformes mobiles. C’est compliqué de faire un rendu riche avec des émojis, par exemple, un gros problème pour une application de messagerie de nos jours.
• le support des portails Freedesktop est inexistant : il faut faire l’implémentation à la main, alors qu’il est natif sur des cadriciels majeurs comme GTK ou Qt. Je pense par exemple à l’ouverture ou l’enregistrement de fichier. Les portails sont particulièrement nécessaires si on veut voir son application sur Flatpak. Plus de détails sur ce ticket.
• le support Wayland existe, mais lors de mes tests sur des distributions GNU/Linux sur Pinephone, il n’a pas fonctionné et je n’ai pas pu afficher l’application.
• le chargement de l’interprète Python prend un certain temps, ce qui rend le lancement de l’application sur plateformes mobiles telle qu’Android et probablement iOS (que je n’ai pas testé) un peu lent. Sachant que sur ces plateformes l’application peut être tuée à n’importe quel moment auquel cas il faut tout relancer, cela peut mener à une mauvaise expérience utilisateur. Ceci dit, avec une distribution optimisée (en enlevant les paquets non utilisés), et sur les téléphones actuels qui sont très puissants, le problème est sans doute moindre.

Notez que je n’ai pas eu l’occasion de travailler avec Kivy récemment, peut-être que ces remarques ne sont plus à jour. Merci d’indiquer en commentaires s’il y a eu de l’évolution sur ces points.

Aussi, mon cas d’utilisation est très demandant (rendu HTML, affichage de texte performant, etc). Dans la plupart des cas, Kivy remplit sans problème toutes les cases (sauf l’accessibilité, qui reste son problème le plus important à mon sens).

Conclusion

Comme vous pouvez le voir, un travail considérable a été effectué sur Kivy et son écosystème, et il en sort un cadriciel performant, pratique, et qui peut potentiellement fonctionner sur la plupart des plateformes. Kivy est agréable à utiliser, et dispose d’une communauté très active et disponible.

Ce cadriciel mérite de s’y attarder, et est une option sérieuse si vous voulez développer un projet rapidement pour une ou plusieurs plateformes.

Une note d’histoire

Cette dépêche a été commencée le 04 octobre 2018 à 14:19 (au premier jour de la Pycon FR 2018, à Lille, où une partie de l’équipe de Kivy était présente). Je crois que c’est haut la main la dépêche qui est restée le plus longtemps dans l’espace de rédaction. Comme quoi, tout vient à point à qui sait attendre, comme dirait l’autre.

Merci à toutes les personnes qui ont participé à la correction de la dépêche.

Cette dépêche fait suite à celle sur les interfaces temps réel ainsi qu’a celle sur l’informatique sans écran. C’est une dépêche de réac qui se plaint que c’était bien mieux avant et qu’on ferait bien d’écouter les anciens un peu plus.

Sommaire

• Retour vers le futur boutonneux
• C’était mieux avant ! (On était jeune)
• Ça change quoi ? Un bouton c’est un bouton, non ?
• Le patch de Colombia
• L’urgence ergonomique
• Bibliographie

C’est une note du blog de ploum qui m’a fait réaliser que l’on a besoin de remettre des boutons, des touches, des joysticks, des potentiomètres linéaires et autres boules de pointage (trackball), souris (boutons et molette), manettes… sur nos ordinateurs, télés, ordiphones, bagnoles et autres mixeurs à soupe mouchard. C’est urgent à l’heure où même nos guitares sont menacées par les écrans tactiles. Bref, une bonne interface Humain/Machine passe par un retour tactile de nos actions : on veut des boutons !

Figure 1 - Refus catégorique de ChatGPT. Peut-être que « Dessine moi un adolescent avec plein de moutons » aurait été mieux accepté. Big Data implique Big Culture, non ?

Retour vers le futur boutonneux

Avant de râler et de déclencher la Guerre des boutons, interrogeons-nous sur ces objets du quotidien. On est sérieux à nôtre âge, on n’a plus dix-sept ans.

Si on considère les touches des claviers d’instruments de musique comme les ancêtres du bouton, alors on peut remonter jusqu’à l’Antiquité et aux premiers orgues : l’hydraule, orgue où l’air est mis sous pression par une chute d’eau, date en effet du III^e siècle avant notre ère (Ctésibios d’Alexandrie). C’est aussi le premier instrument à clavier. Ses touches avaient probablement des mécanismes très simples et il n’y avait pas de touches blanches et noires, comme dans cette reconstitution d’un orgue antique (avec même le son dans la vidéo). Vers 320-322 de notre ère, Claudien écrit un poème contenant ces vers :

« Qu’un autre enfantant, par une légère pression, des sons au loin retentissant, modère les mille voix de mille tuyaux d’airain, les fasse tonner sous ses doigts errants, et d’une onde profondément agitée par le jeu du levier, tire d’harmonieuses modulations. » (Panégyrique sur le consulat de Flavius Mallius Theodorus)

Figure 2 - Reconstitution d’un orgue romain. [Source : Wikimedia, domaine public]

On trouve déjà dans cette description le constat qu’il suffit d’appuyer sur un bouton pour déclencher des tâches mobilisant une grande puissance. Seize siècles plus tard, en pleine guerre froide et deux ans après la crise des missiles de Cuba, le jeune Bob Dylan (22 ans) chante dans With God On Our Side (The Times They Are A-Changin’, 1964) :

One push of the button
And a shot the world wide

Figure 3 - Tableau de bord des missiles de croisière nucléaires du sous-marin USS Growler (1958-1964). [Source : Wikimedia, licence : CC-BY-SA par Flintmichigan]

C’est en fait dans les deux dernières décennies du XIX^e siècle, avec la diffusion de l’électricité dans les villes, que se produit la grande éruption des boutons. Nous avons bien sûr oublié à quel point c’était magique à l’époque ! Mais on s’inquiète aussi rapidement de l’avènement d’une humanité presse-bouton :

Plotnick cite un éducateur et activiste de 1916 déplorant que le fait d’appuyer sur un bouton « semble nous décharger de toute nécessité de se sentir responsable quant à ce qui se passe derrière le bouton ».

Les récits d’anticipation s’en emparent. Par exemple, Edward Morgan Forster publie en 1909 une nouvelle intitulée The Machine Stops (La Machine s’arrête) dans laquelle les êtres humains vivent sous terre isolés chacun dans une pièce, quasiment sans contact physique, la Machine satisfaisant tous leurs besoins :

Puis elle activa la lumière, et la vue de sa chambre, inondée de lumière et constellée de boutons électriques, la revigora. Il y avait des boutons et des interrupteurs partout - des boutons pour demander de la nourriture, de la musique, des vêtements. Il y avait le bouton du bain chaud, qui faisait surgir du sol une cuve en (faux) marbre, remplie à ras bord d’un liquide chaud et désodorisé. Il y avait le bouton du bain froid. Il y avait le bouton qui produisait de la littérature. Et il y avait bien sûr les boutons qui lui permettaient de communiquer avec ses amis. La chambre, bien que ne contenant rien, était connectée avec tout ce qui lui importait dans le monde. (Version originale en ligne sur The Project Gutenberg et version française éditée par l’échappée)

C’était mieux avant ! (On était jeune)

Tout râleur qui tient à sa crédibilité se doit de râler en connaissance de cause. On n’ira donc pas jusqu’à prétendre que c’était mieux sans bouton et on se contentera de notre vécu : c’était mieux avant quand il y avait de vrais boutons ! Qu’on pouvait pressurer et qui faisaient de vrais sons, « des clip, crap, des bang, des vlop et des zip », qui résistaient, qui vibraient, qui glissaient ! Bref, qui nous donnaient des sensations.

Figure 4 - Malgré cet appel touchant, les portes de la perception semblent désormais presque fermées. Le monde est devenu plat et lisse ; les êtres humains se sont enfermés dans leur caverne numérique. [Source : Wikimedia, licence : CC-BY par SunOfErat]

Bien que la technologie des écrans tactiles soit assez ancienne, c’est surtout l’envolée des ventes de smartphones et tablettes autour de 2010 qui va propager les interfaces tactiles à d’autres objets du quotidien : des appareils électroménagers jusqu’aux voitures, pour le meilleur et pour le pire. Probablement parce qu’un écran tactile avec des menus permet de remplacer de nombreux boutons et aussi par effet de mode (ça fait moderne, en attendant les interfaces cérébrales). Dans nos interfaces graphiques, telles que GTK, on retrouve des ersatz de boutons : interrupteurs On/Off, boutons radio (quand on presse sur l’un, l’autre ressort), commutateurs (switches), etc. Mais tout ça manque de relief !

Sur les lecteurs de K7, on pouvait avoir des boutons poussoir qui remettaient à zéro le compteur (mécanique). Et également des boutons qu’on poussait vers le bas et qui restaient bloqués (lecture) ou non (éjection). Press the Eject and Give Me the Tape est par exemple le titre d’un album live du groupe britannique Bauhaus sorti en 1982.

Figure 5 - Un magnétophone : appuie sur Eject et file-moi la K7 ! [Source : Wikimedia, domaine public]

Sur une chaîne Hi-Fi, on trouve de bons gros boutons cylindriques que l’on peut prendre à pleine main. Ils peuvent être continus (par exemple pour le volume), c’est-à-dire que ce sont des potentiomètres rotatifs, ou à crans (par exemple pour sélectionner une source). Ces gros boutons ont été longtemps également utilisés pour sélectionner les fréquences des stations de radio et ils faisaient bouger un curseur au-dessus des graduations. Sur nos chaînes, on peut aussi avoir des boutons de type manette, avec deux positions ou plus. Sur les radio-K7 on pouvait également rencontrer des potentiomètres linéaires pour régler le volume ou la tonalité. On les utilise aussi sur les égaliseurs, comme ci-dessous.

Figure 6 - Une éruption de boutons divers et variés, sensations garanties [source : Wikimedia, licence : CC0].

Dans la suite de cette dépêche, on va surtout évoquer les boutons poussoir (qu’ils restent bloqués ou non) car ce sont ceux que l’on rencontre le plus dans les interfaces tactiles. Mais le discours serait similaire pour les autres types de boutons.

Ça change quoi ? Un bouton c’est un bouton, non ?

Le problème de l’écran tactile, c’est que c’est l’écran qui est tactile, qui touche, qui sent notre doigt. Le doigt, quant à lui, sent juste qu’il a touché une surface, mais il ne sait pas s’il est au bon endroit. L’écran est soi-disant tactile, mais c’est avant tout un écran, ce qui implique la vue. Lorsque l’on touche le bouton avec son doigt, on le cache. Pour savoir s’il on a bien appuyé sur le bouton il faut donc retirer son doigt et regarder à nouveau si le bouton virtuel a changé d’état.

Du point de vue de l’utilisateur, on a donc plutôt affaire à des « boutons visuels » plutôt qu’à un « écran tactile ». Tout au plus l’émission d’un clic électronique ou d’une vibration non localisée confirmera qu’on a appuyé sur un bouton (parmi d’autres).

Avec de vrais boutons, c’est du 3D. Si on a mémorisé leur disposition, on peut s’en sortir sans la vue, uniquement au toucher. Intéressant quand on conduit par exemple, les doigts se promènent par exemple sur les six boutons pour choisir la station de radio et trouvent sans problème le troisième bouton. Une personne aveugle sera bien démunie face à un écran tactile. Un bouton mécanique est quant à lui vraiment tactile, c’est-à-dire que les doigts le sentent : le toucher prédomine alors sur la vision. D’ailleurs en français, les « boutons » d’un clavier, qu’il soit musical ou informatique, s’appellent des touches.

On peut aussi noter que les vrais boutons sont généralement en nombre limité (car ça prend de la place et ça coûte). Ils permettent donc d’effectuer les actions les plus courantes. Les écrans permettent de créer des menus, pour des choix plus complexes. Mais cela peut être redoutable pour certaines personnes âgées, qui n’ont pas été habituées à ces technologies, ou dont les fonctions cérébrales déclinent. Ne parlons même pas des mises à jours logiciels incessantes qui changent l’aspect et la disposition des menus.
Le pire étant le manque de performance (c'est rarement temps réel) qui nous force souvent à ré-apppuyer pour se retrouver avec un comportement que l'on avait pas prévu quand ça se débloque.

Autre problème, on a parfois besoin de protéger ses doigts avec des gants, qu’il fasse froid ou qu’on soit en train de faire une activité dangereuse pour les mains. Un bon vieux bouton reste généralement utilisable. Même avec des moufles, on pourra encore y arriver si les boutons ne sont pas trop rapprochés !

Figure 7 - Parfois on doit travailler avec des gants, ce qui entraîne une perte au niveau tactile. Il y a vraiment là de quoi faire la moue. [Source : Wikimedia, domaine public]

Revenons sur le son. Les boutons sur lesquels on appuie émettent souvent un son qui constitue un retour sensoriel supplémentaire qui nous indique si nous les avons correctement enfoncés. Au point que l’on parle de « cliquer » sur le bouton d’une souris plutôt que d’appuyer dessus. On a donc à la fois un retour tactile (une certaine résistance ou vibration) et un retour sonore, en plus de l’éventuel retour visuel si on regarde le bouton.

Avec un écran dit tactile, le retour tactile est justement bien maigre, on ne fait qu’effleurer les choses : la pression exercée importe peu, la résistance opposée par l’écran sera la même si j’appuie sur le soit-disant bouton ou à côté ! Et le vibreur de mon téléphone fera vibrer tout le téléphone au lieu de ne faire vibrer que l’endroit où j’ai appuyé. Triste topique…

Le patch de Colombia

Les constructeurs d'ordiphone s'échinent à virer les boutons de leurs appareils ? Qu'à cela ne tienne, des étudiants de l'Université de Colombia proposent une coque pour en remettre !

Sans aucune connexion électrique, ces étudiants proposent de faire vibrer le téléphone au moyen de clapet et ressort et de les détecter en utilisant l'accéléromètre.

Le type de vibration reçue permet à un logiciel de traitement du signal de détecter le type de bouton actionné et ainsi récupérer la fonctionnalité perdue.

C'est intéressant, mais pourquoi ne pas tout simplement nous rendre nos boutons !

L’urgence ergonomique

Nous savons bien que les temps changent, mais il ne faut pas céder à la mode sans raison. L’écran tactile peut être adapté à certaines machines ou situations et pas à d’autres. Faut-il vraiment « être absolument moderne », juste pour le plaisir ? Non, il faut être absolument ergonomique. Alors, si vous ne voulez pas vous faire appeler Arthur, rendez-nous nos bons vieux boutons là où ils sont parfaitement adaptés à nos besoins ! Rouvrons les portes de la perception !

Figure 8 - Un adolescent peut aussi avoir des boutons au niveau de son gilet. De plus, en voilà un qui ne sourit pas et n’a pas l’air niais. Ce qui finalement justifie peut-être le refus de ChatGPT en haut de cette dépêche. [Source : Wikimedia, Étienne Carjat (1871), domaine public]

Bibliographie

• Gwendolyn Rak, « Touchscreens Are Out, and Tactile Controls Are Back - Rachel Plotnick’s “re-buttonization” expertise is in demand », IEEE Spectrum, 3 nov. 2024.
• Rachel Plotnick, « At the Interface: The Case of the Electric Push Button, 1880–1923 », Technology and Culture 53 (4): 815‑45, 2012.
• Dans Wikipedia : Bouton (électricité), Interrupteur, Push-button.
• Entrée Bouton dans le dictionnaire TLFi.