Interview de Cédric Bellegarde, développeur de Lollypop

Régulièrement, lors des sorties de nouvelles versions de GNOME ou KDE (voir de tout autre environnement de bureau), des utilisateurs des différentes communautés se lancent dans des flamewars pour mettre en avant leurs propres choix et dénigrer ceux de l’adversaire. Pour les personnes ne s’intéressant pas particulièrement à la technique, il est parfois difficile de faire la part du vrai, et j’ai donc trouvé intéressant d’interroger Cédric à ce sujet, qui connaît bien ces deux environnements pour avoir développé sur l’un et l’autre.

Et nous en profiterons bien évidemment pour en savoir plus sur l’avenir de Lollypop, dont la dernière version de cet excellent lecteur de musique vient tout juste de sortir.

Peux-tu te présenter brièvement, ainsi que ton parcours ?

Alors, Cédric Bellegarde, je vis dans l’Anjou, j’ai une formation niveau DUT très orientée développement. Malgré cela, ma seule expérience professionnelle dans ce domaine est mon stage de fin d’études chez Aliacom sur le logiciel OBM (chez Linagora aujourd’hui). Je me suis ensuite orienté dans l’administration système et réseau dans le milieu universitaire.

Dans le domaine du libre, j’ai dès 2003/2004 rencontré la communauté Mandrake française en contribuant à quelques paquets pour la distribution. Par la suite, de 2006 à 2007, je contribue activement au projet Compiz et Compiz-Fusion sur la gestion des fenêtres en particulier. En 2007, première expérience avec Python+GTK avec un client MPD (sources, capture d’écran).

Fin 2008, je migre sous KDE4,  je contribue à différents projets : rekonq, oxygen-gtk, kdepim… En 2013, un projet attire mon attention, se baser sur le travail de Canonical pour déporter la barre de menu de manière native sous KDE. Je me lance donc dans kded-appmenu et contribue directement à Kwin.

Par la suite, je me rends compte que j’ai de plus en plus de mal avec le bureau de KDE et certaines applications qui sont bien trop complexes, mais GNOME 3 ne me donne pas du tout satisfaction.

Il faudra attendre la sortie de GNOME 3.12 pour que je sois conquis et commence à imaginer le lecteur  de musique de mes rêves.

Au vu du grand nombre de lecteurs audio sous Linux, qu’est-ce qui t’a poussé à te lancer dans le développement d’un tout nouveau projet ?

J’ai d’abord utilisé Musique avec plus ou moins de succès, mais il était très lent, trop lent…  Après avoir étudié le code de ce dernier et trouvé le goulot d’étranglement (tracker), j’ai migré temporairement sous Clementine et commencé à développer Lollypop en reprenant les concepts de base de GNOME Musique.

Concevoir une bonne interface, agréable à utiliser et bien pensée, est une tâche difficile. Quelles difficultés as-tu rencontré, et est-ce que les GNOME Human Interface Guidelines t’ont été utiles, durant ce processus ?

C’est en parti ces règles qui m’ont fait passer sous GNOME. J’aime beaucoup le « look & feel » des applications GNOME et j’ai construit Lollypop autour de ces principes, qui sont assez proche de ce que fait Apple sur certains points, mais avec une contrainte en plus : pas de menu global à l’application. Je trouve aussi que les nouveautés de GTK+ sont vraiment les bienvenues après de nombreuses années de stagnation et permettent d’explorer de nouvelles façons de concevoir une application.

Quelle distribution utilises-tu, et quels sont tes outils de développement ?

Je développe principalement sous Fedora et Debian/Ubuntu. Comme outils, simplement Gedit/Devhelp et Glade.

As-tu suivi le développement de Builder, l’IDE pensé pour faciliter le développement d’applications GNOME ? Penses-tu que ça aille dans le bon sens, et envisages-tu de l’utiliser, à terme ?

Oui, cela va dans le bon sens, mais je trouve dommage que cette étape arrive avant la mise à niveau de Glade qui ne gère pas du tout les nouveautés de GTK+.

J’ai lu sur LinuxFR que tu étais auparavant sous KDE. En tant que développeur, le changement de technologies fut-il aisé ?

Oui, les principes sont les mêmes… Python/GTK+ ou C++/Qt, c’est relativement la même chose, même si Python permet vraiment de développer plus rapidement que C++. Par contre, j’ai trouvé plus de réponses à mes questions sur le web lors du développement de Lollypop que pour mon travail sur KDE…

On reproche souvent à GNOME et ses différentes technologies (Gtk+, GStreamer…), d’être moins bien documentés que certains « concurrents ». La situation est-elle réellement si mauvaise ?

La documentation de GTK+ est toujours moins bonne que celle de Qt, mais les moyens ne sont pas les mêmes. De plus, la documentation des bindings est bien meilleure côté GTK+. C’est surtout la documentation de KDE qui n’est pas au niveau ni de Qt ni de GTK+/GNOME.

Un autre reproche qui revient régulièrement, est de devoir faire de l’orienté objet avec du C. GNOME offrant la possibilité d’utiliser le langage de son choix, en tant que développeur Python d’une application utilisateur, en as-tu souffert ? Est-ce que ça t’a contraint à adapter ta façon de développer ?

Effectivement, je n’aime pas du tout le couple C/Gobject mais cela permet à GNOME d’offrir des bindings à jour pour de nombreux langages via Gobject Introspection, ce qui n’est pas le cas sous KDE. De plus, entre Vala et Python, je pense que personne n’a besoin de faire de l’orienté objet avec du C pour faire une application GNOME.

De toutes les possibilités offertes par la plate-forme GNOME, qu’est-ce qui t’a le plus plu ?

GtkHeaderBar (la barre d’en-tête, ndr) sans hésiter. Une grande avancée. Depuis le temps que je voulais voir une nouvelle façon de faire des applications sous GNU/Linux. C’est la suite logique de mon travail sur KDE. Je ne supporte pas les barres de menus. GNOME a réussi à les reléguer au second rang. Côté KDE, ils veulent faire à terme communiquer le gestionnaire de fenêtres avec l’application, mais du point de vu du développeur cela n’offrira jamais la flexibilité de GtkHeaderBar.

Quels conseils donnerais-tu à un développeur GNOME débutant, qui souhaiterait se lancer dans le développement d’une nouvelle application ?

Commencer par contribuer à un outil existant afin de mieux se familiariser avec l’environnement. Je n’ai pas un énorme niveau en programmation et j’ai beaucoup appris des mes contributions à Compiz et KDE. Il ne faut pas croire qu’il faut être ingénieur pour faire ce boulot. On est sur du haut niveau, je n’aurai pas la prétention de savoir coder Lollypop en C sans GStreamer :)

J’ai cru comprendre que tu t’occupais toi-même de la création de paquets pour Arch, Fedora, Ubuntu… N’est-ce pas trop pénible, quand on sort régulièrement de nouvelles versions ? Pourquoi ne pas avoir délégué cette tâche ?

Une fois Lollypop intégré dans les distributions, je ne ferais plus les paquets… Sauf si j’ai toujours le temps de fournir la dernière version.

D’avoir aujourd’hui autant de distributions et d’environnements de bureau (GNOME, Pantheon, Unity…), rend-il les tests qualité plus nombreux et difficiles ?

Oui pour Unity, car Canonical rejette les paradigmes de GNOME (la barre d’en-tête en particulier). Pour le reste, cela ne change rien, ils sont tous compatibles avec GNOME.

GNOME et Red Hat ont commencé à travailler sur le support des applications sandboxées. L’un des avantages étant de pouvoir permettre à des développeurs tiers de fournir un paquet unique qui tournerait partout, sans avoir à se soucier de la distribution ou de la version de GNOME utilisées par l’utilisateur. En tant que développeur et responsable de paquets, qu’en penses-tu ?

Que c’est une très bonne chose, car il est effectivement chiant de faire des paquets pour toutes les distributions. Reste à voir si la mayonnaise prend, mais d’un point de vue technique ça me semble bien pensé.

Trop d’options et de fonctionnalités rendent souvent les interfaces plus chargées et les applications plus difficiles à prendre en main. Penses-tu être proche de cette limite, ou as-tu encore de nombreuses idées à implémenter ?

Avec la 0.9.30 qui sort demain (à l’heure où je réponds à cette question), j’ai fais le tour, c’est la dernière version avec de nouvelles fonctionnalités avant la 1.0. Après, je rajouterai des fonctions si les propositions me semblent pertinentes.

Un grand merci à Cédric d’avoir bien voulu prendre le temps de répondre à mes quelques questions ;)

GNOME 3.18 supportera différents types de capteurs

Les tablettes et les ordinateurs portables modernes sont désormais truffés de capteurs : un accéléromètre pour le positionnement de l’écran, un capteur de lumière ambiante pour ajuster la luminosité de l’écran, un compas gyroscopique pour la navigation…

Suite aux travaux sur la WeTab, GNOME et Linux supportaient déjà les accéléromètres depuis plusieurs années, mais certains changements apportés par Windows 8 et les périphériques compatibles avec ce dernier ont poussé à tout remettre à plat.

Bastien Nocera a donc développé le projet iio-sensor-proxy, dont la version 1.0 vient tout juste de sortir. En plus des accéléromètres, cette première version stable supporte également les capteurs de lumière ambiante, ce qui signifie qu’en plus de pouvoir s’adapter automatiquement à une rotation de l’écran, GNOME 3.18 pourra également adapter, tout aussi automatiquement, la luminosité de ce dernier.

Dans les prochaines versions, il est prévu de pouvoir exporter les données brutes de l’accéléromètre pour qu’elles puissent être utilisées par les applications. Ce qui pourrait être intéressant dans le cas de jeux vidéos. Il est également prévu d’ajouter le support du compas gyroscopique, dont les informations seront communiquées au service de géolocalisation GeoClue, permettant ainsi d’obtenir l’emplacement et la direction avec une même API.


Histoire de mieux comprendre le projet, s’ensuit un petit entretien avec Bastien Nocera, que je remercie encore une fois pour le temps qu’il a bien voulu m’accorder ;)

Le projet s’appuie sur systemd. Qu’apporte réellement ce dernier, et cela a t’il permis de simplifier le développement ?

Dans ce cas précis, systemd/udev est uniquement utilisé pour lancer le daemon en tâche de fond, quand un capteur apparaît (lors du démarrage, lorsque qu’on sort du sommeil, ou, comme pour le ColorHug ALS, s’il est branché en USB). systemd permet de simplifier le lancement de services D-Bus lorsqu’ils sont attachés à un périphérique amovible. C’est aussi la manière dont bluetoothd, le daemon qui s’occupe du Bluetooth, fonctionne.

Utiliser un autre système d’init est parfaitement possible, mais moins pratique, et surtout inutile étant donné que toutes les distributions majeures de Linux utilisent systemd (et que iio-sensor-proxy ne fonctionne que sur Linux).

Les capteurs semblent être reconnus comme des périphériques HID. Est -ce que ça implique une certaine normalisation, offrant par défaut, une fois le pilote initial développé, le support de tous les capteurs d’un même type, ou est-ce qu’il faudra développer des pilotes différents pour chaque capteur de chaque fabricant ?

Certains capteurs sont des capteurs HID, mais pas tous. Pour avoir le tampon de certification pour Windows 8, les capteurs doivent utiliser HID pour exporter leurs données, et le faire d’une certaine manière. Cependant, sous Linux, les capteurs sont souvent, de toute façon, gérés par la surcouche du noyau IIO (« Industrial I/O », entrées-sorties industrielles). Ce qui nous permet de gérer à la fois les capteurs basés sur le HID que supporte Windows 8 par défaut, ainsi que de nombreux autres que les constructeurs peuvent intégrer dans leurs systèmes.

Les capteurs mono-fonctions plus anciens, comme ceux de la WeTab, sont eux encore différents, apparaissant comme de vrais périphériques d’entrée, tels une souris, mais avec Z, l’axe de la profondeur, en plus. Nous supportons aussi les capteurs utilisés sur MacBook, qui sont exportés par le noyau Linux de manière différente. En clair, les capteurs HID compatibles Windows 8 bénéficieront de pilotes Linux déjà intégrés, mais les autres, avec un driver IIO supporté, fonctionneront aussi.

Dans le cas des capteurs de lumière ambiante, j’ai cru comprendre que les différents fabricants n’utilisaient pas une unité de mesure commune et normalisée. Comment avez-vous procédé pour pouvoir tout de même offrir à l’utilisateur un système unifié ?

Dans ce cas, le problème n’est plus dans iio-sensor-proxy lui-même. Le daemon exporte le fait que les données sont sans unité, ramenées à un pourcentage et les applications se débrouillent pour savoir si elles peuvent gérer ces données. Dans le cas de gnome-settings-daemon (une tâche de fond qui gère l’énergie sous GNOME), nous utilisons les préférences de l’utilisateur pour calibrer les changements de luminosité de l’écran, et « apprend ». Pour plus de détails, il vaut mieux inspecter le patch écrit par Richard Hughes directement.

Comment est gérée la sécurité, pour qu’un programme malicieux ne puisse pas accéder à certaines informations sensibles, comme la localisation de l’utilisateur et la direction prise ?

Pour l’instant, le problème ne se pose pas : nous n’exportons pas aux applications les données brutes des accéléromètres, ou les données des compas électroniques. Dans le futur, les données du compas ne seront disponibles que pour GeoClue, qui renverra ces données vers les applications de géolocalisation, telles que Cartes ou Météo, avec les mêmes demandes de permission.

Pour ce qui est de l’accéléromètre, le même système sera mis en place. Dans les deux cas de figure, nous attendons un déploiement plus généralisé des technologies utilisées, comme kdbus et xdg-app.

Les intéressés peuvent suivre le développement de cette fonctionnalité sur GitHub.