Qt dans Ubuntu ! Des morts à venir ?

Cela bouge énormément au niveau du desktop de la distribution GNU/Linux orientée desktop la plus connue et la plus utilisée, j’ai nommé Ubuntu, bien sûr basée sur Debian. Et ce qui se passe pourrait transformer radicalement le paysage du logiciel libre pour le bureau de l’utilisateur final.

L’abandon de GNOME pour Unity, puis la volonté de s’émanciper à moyen terme de Xorg pour aller vers Wayland, étaient déjà des annonces retentissantes. Deux grandes nouvelles sont venues s’y ajouter en ce début d’année. Des annonces concernant l’un des plus grands trolls de l’histoire du logiciel libre, le grand combat des jeux de widgets Qt VS GTK.

En effet, en tant que distribution GNOME, Ubuntu avait l’ensemble de sa stack graphique basée sur GTK et les technologies dérivées. C’est Kubuntu, distribution KDE officiellement supportée, qui intégrait Qt. Or, dans les prochaines versions d’Ubuntu, cet équilibre qui semblait à la fois si stable et si évident va littéralement voler en éclats.

Unity 2D

Le 13 janvier c’est Bill Filler qui annonçait Unity 2D, un clone de l’interface Unity ne nécessitant pas d’accélération 3D et se basant sur Qt. La problématique est très importante, car Ubuntu ne peut se permettre avec son Unity 3D de tourner le dos aux machines du passé, qui peuvent ne pas avoir les capacités graphiques nécessaires mais continuent malgré tout de fonctionner, et surtout aux machines de l’avenir, qui seront de plus en plus basées sur des processeurs ARM et donc souvent dénuées de chip 3D ou de drivers libres.

Ce problème avait déjà été réglé par Canonical qui fournit depuis Ubuntu 10.04 une version 2D d’Ubuntu Netbook Edition. Cette dernière repose sur les EFL, pour Enlightenment Foundation Libraries, connues pour proposer de belles et rapides fonctionnalités graphiques sans accélération 3D. Je peux d’ailleurs témoigner de la qualité de l’ensemble, puisque c’est ce qu’utilise ma sœur sur son Toshiba AC100.

Une infidélité avec les EFL pour l’interface d’une distribution GNOME passe encore, mais avec Qt ! Ne manquait plus que les applications…

Applications Qt

Le 18 janvier c’est Mark Shuttleworth en personne qui annonçait que de la place sera réservée pour Qt sur le CD de Natty+1, c’est-à-dire Ubuntu 11.10, et que toute application se basant dessus se trouvait donc désormais en position d’intégrer Ubuntu. Des applications ne se trouveront donc plus exclues du simple fait de leur bibliothèque graphique, et la sélection ne se fera donc plus que sur leurs qualités intrinsèques. Présenté ainsi, cela paraît difficilement contestable du point de vue de l’ingénierie logicielle.

En fait c’est un secret de Polichinelle que GTK a toujours été techniquement inférieure, ou au moins en retard sur Qt. Qt qui de plus a toujours été parfaitement multiplateforme (X11, MacOS X et Windows), alors que GTK a mis du temps à fonctionner sous Windows et n’a jamais supporté MacOS X en natif. Qt qui est basée sur C++, alors que GTK est basée sur C, avec un modèle objet parfait pour un programmeur assembleur, mais peu convainquant pour un programmeur Eiffel. Pour un programmeur Python, le fait de ne pas pouvoir faire d’héritage multiple est une limitation qui parle, encore plus quand on lui ajoute l’argumentaire “it’s not a bug, it’s a feature”.

Alors pourquoi tant de développeurs du libre, y compris moi, utilisent-ils GTK plutôt que Qt ? La raison qui a poussé à l’adoption de GTK a été d’abord l’éthique, puisque Qt n’était pas libre. Ensuite, la nature multiplateforme de Qt qui fournissait bien plus de technologies qu’un simple toolkit graphique a plutôt joué en sa défaveur, alors que GTK s’intégrait beaucoup mieux avec les autres technologies libres développées pour Linux, ce qui l’a fait peu ou prou apparaître comme la bibliothèque graphique native de ce système.

Pourquoi Qt maintenant ?

Oui mais voilà, Canonical veut faire des choix radicaux et forts motivés par l’excellence technique. Il  faut bien reconnaître qu’une distribution Linux desktop qui envisage sans frémir d’abandonner X11, et presque 30 années d’histoire de l’affichage graphique pour Unix, peut bien changer de toolkit.

QML, un langage déclaratif de description d’interface graphique proche de JavaFX, c’est-à-dire avec une syntaxe qui N’est PAS du XML mais du JavaScript et de nombreuses fonctionnalités graphiques modernes comme les animations, est l’argument technique majeur avancé. Ainsi toute l’interface d’Unity 2D est-elle écrite en QML.

Le fait qu’une grande entreprise aussi riche que Nokia mette toute sa puissance, et ses nombreux développeurs payés à plein temps, derrière Qt qu’elle a racheté en 2008 pour plus de 100 millions d’euros, est aussi un élément qui doit beaucoup peser du côté de Canonical.

To the good folks at Trolltech, now Nokia, who have made Qt a great toolkit – thank you.

L’ergonomie en question

Je ne peux que constater depuis des années la piètre qualité de l’ergonomie générale (cohérence de l’interface, consistance des actions, stabilité entre les versions, design, etc.) des principaux bureaux libres que sont GNOME et KDE, à tel point que bien que plus fonctionnels, je les considère toujours comme inférieurs à Window Maker, un clone de NeXTSTEP, l’ancêtre de MacOS X.

La première explication de cette situation est le fait que les excellents développeurs que sont ceux du logiciel libre sont rarement aussi de bon ergonomes ou de bons designers (pour ceux ne se limitant pas volontairement à la CLI). La seconde explication est que le modèle décentralisé où chacun peut apporter ses idées et améliorer celles des autres, si efficace pour développer des logiciels toujours plus inventifs et innovants, ne l’est plus du tout quand il s’agit de créer une interface graphique cohérente.

Mark Shuttleworth s’est désigné volontaire pour jouer le rôle du salaud autoritaire fascisant que Steve Jobs tient avec succès chez Apple depuis toujours, et je pense qu’il a raison. Ainsi la première chose que j’ai remarqué en testant Unity, c’est que je ne pouvais pas mettre le dock à droite, ce qui en tant que droitier est réellement problématique pour moi. Ce bug dont au moins 20 autres personnes semblent déjà souffrir, a été marqué comme “wontfix” par Shuttleworth car il veut absolument que le dock soit proche du bouton Ubuntu ! C’est horrible, c’est nazi, mais ça se tient. Et personnellement, quand on voit le résultat global d’Unity, on est déjà bien loin devant GNOME et KDE en terme d’ergonomie (j’y reviendrai plus longuement dans un autre article).

Des morts à venir ?

Je pense que cet effort de réunir tous les meilleurs logiciels libres, quelles que soient leurs technologies, dans Ubuntu, va inéluctablement amener à la disparition de ses dérivés officiels Kubuntu et Xubuntu (basé sur Xfce).

Si l’on est conscient de la place prédominante qu’occupe aujourd’hui Ubuntu parmi les distributions orientées desktop, et si Shuttleworth réussit son coup avec Unity, on peut même légitimement se poser la question de la pérennité des projets GNOME et KDE.

GNOME me paraît le plus en danger, au moins au sens où on l’entend aujourd’hui comme bureau graphique, puisque Shuttleworth l’envisage plutôt comme l’ensemble des bibliothèques non-graphiques, et ose même un surréaliste :

Perhaps GNOME itself will embrace Qt

qui démontre sans équivoque le peu de crédit qu’il porte à GTK. De plus la prochaine version du bureau GNOME, nommée GNOME shell, utilisera Mutter et Clutter, qu’Unity a déjà abandonnés en faveur de Compiz et Nux (un nouveau toolkit graphique 100% OpenGL) car étant à la fois trop lents et trop buggés.

Et si le duo Compiz/Nux ne se montrait finalement pas à la hauteur… Unity 2D pourrait tout aussi bien se transformer en Unity 3D avec le prochain SceneGraph. Et comme en plus Qt est la première bibliothèque graphique à peu près portée sur Wayland…

Mais il ne faut pas s’y tromper, adopter Qt ne semble pas du tout vouloir dire switcher vers KDE :

I’d draw a distinction between “Qt” and “KDE” in the obvious places.

Paradoxalement, l’adoption généralisée de son toolkit pourrait bien quand même marquer la fin de KDE, puisqu’un développeur censé voudra logiquement utiliser Qt, mais aucune dépendance particulière à KDE qui empêcherait l’intégration de son application dans Ubuntu.