Design sprint autour de Logiciels

Il y a quelques semaines, plusieurs personnes de chez Canonical (de l’équipe en charge de la boutique, de Snap, du design et du desktop) ainsi que Richard Hughes, le mainteneur de Logiciels, se sont réunis à Londres pour discuter d’une liste d’améliorations possibles concernant la logithèque.

La page d’accueil de l’actuel Logiciels 3.28

Parmi les nombreuses idées qui ont été discutées, on peut retenir :

  • Des éditeurs (développeurs) certifiés. Un moyen de signaler à l’utilisateur qu’un éditeur a subi un contrôle prouvant qu’il est bien celui qu’il prétend être. Cela sera d’autant plus utile qu’avec la démocratisation à venir des paquets Flatpak ou Snap qui pourront être fournis directement par les développeurs sans passer par les packageurs de la distribution, les utilisateurs auront besoin de s’assurer qu’ils n’installent pas des applications dangereuses. Et là, on pense tout de suite à la récente affaire des malwares cachés dans certains paquets Snap de la boutique Ubuntu.
  • Une façon de signaler des problèmes avec les applications. Que ce soit directement auprès de l’éditeur ou par l’intermédiaire de la logithèque.
  • Une présentation améliorée et la possibilité pour les éditeurs d’ajouter des thèmes et des illustrations supplémentaires à la page de leur application. Les différentes propositions incluent l’ajout de badges pour montrer qu’une application est populaire dans certaines catégories, son niveau de confinement, la possibilité d’ajouter une bannière personnalisée, la prise en charge des GIFs et des vidéos (ce qui pourrait donner plus facilement une première idée des possibilités d’une application ou d’un jeu avant son téléchargement).
  • Un écran d’accueil rafraîchi pour faire apparaître de nouvelles applications, des applications ou des greffons liés à ce que l’utilisateur a déjà installé, ainsi que des nouvelles et des mises à jour en provenance de nos développeurs d’applications préférées.

Il est prévu que les maquettes soient ajoutées sur GitLab pour être discutées publiquement, mais pour le moment, il n’y a malheureusement rien à se mettre sous la dent.

Une chose est sûre, un ravalement de façade ne sera pas du luxe, surtout quand on voit à quel point la version actuelle fait vieillotte en comparaison du tout nouveau Mac App Store qui doit débarquer cet automne (quel troll gratuit 😁).

Maintenant, le côté cosmétique c’est bien, mais je ne cacherai pas que j’aimerai bien qu’ils améliorent la fiabilité et qu’ils implémentent certaines fonctionnalités, dont on a bien du mal à comprendre qu’elles soient toujours absentes (surtout après cinq années de développement). Comme l’état d’avancement et la durée estimée pour le téléchargement des mises à jour ou la possibilité de définir le pourcentage de bande passante réservé à ces mêmes téléchargements.

Hackathon GNOME pour l’amélioration des performances

GNOME Performance Hackfest 2018 (© Alberto Ruiz)

Les fondations GNOME et Raspberry Pi ont récemment organisé un hackathon ayant pour objectif l’optimisation des ressources (RAM, CPU, GPU, consommation énergétique) utilisées par une session GNOME typique, ainsi que l’amélioration des performances.

L’événement s’est déroulé du 14 au 16 mai 2018 à Cambridge et a réuni plus d’une quinzaine de développeurs issus de diverses entreprises telles que Broadcom, Canonical, Collabora, Endless et bien évidemment Red Hat, dont les développeurs étaient présents en nombre.

Parmi les différents problèmes d’utilisation de la mémoire sur lesquels les développeurs ont travaillé, nous pouvons citer le gestionnaire de session GDM, qui maintient sa propre instance de GNOME Shell. De régler ce problème fait chuter la consommation de RAM de 280 Mio. Rien que ça. Autre cible importante, Logiciels, la logithèque GNOME, qui tourne en tâche de fond pour pouvoir fournir des résultats lors d’une recherche d’applications dans la vue d’ensemble des activités. Ce dernier consomme plus de 90 Mio de RAM. Sans oublier tous ces petits démons qui pourraient être appelés à la demande, plutôt que de tourner en permanence.

Le travail est loin d’être terminé, mais GNOME 3.30, dont la sortie est prévue pour le mois de septembre prochain, devrait, à n’en pas douter, être bien plus léger et réactif qu’il ne l’est actuellement.

Ceux qui souhaitent en apprendre plus peuvent consulter les billets de blog (en anglais) d’Alberto Ruiz et de Carlos Garnacho.

GTK+ 4.0 ne sera pas GTK+ 4

GTK+ Hackfest 2016 (© Matthias Clasen)

Le GTK+ Hackfest 2016 se déroule en ce moment même à Toronto. Plus d’une quinzaine de développeurs s’y sont retrouvés pour trois jours de développement et de discussions, décidant ainsi du futur de cette bibliothèque utilisée pour concevoir les interfaces graphiques des applications GNOME et d’un certain nombre d’autres projets majeurs.

L’une des discussions ayant fait le plus de bruit concerne le versionnage des prochaines versions majeures (GTK+ 4, 5, 6…).

Depuis la sortie de GTK+ 3.0 en février 2011, les nouvelles versions mineures se sont succédé ces dernières années, apportant à chaque fois leur lot de nouvelles fonctionnalités, mais également de problèmes, cassant régulièrement l’API ou les thèmes utilisateurs. À tel point que ce manque de compatibilité ascendante est désormais l’une des critiques les plus courantes, et que différents projets ont préféré abandonner GTK+ au profit de Qt, ou de retarder leur migration de GTK+ 2 vers la version 3.

Pour rappel, GTK+ 1 est sorti en 1998, GTK+ 2 en 2002 et GTK+ 3 en 2011. Des écarts toujours plus grands, qui obligent à apporter régulièrement de nouvelles fonctionnalités pour pouvoir coller aux nouvelles technologies ou couvrir de nouveaux besoins.

L’une des solutions envisagées, serait de sortir plus régulièrement de nouvelles versions majeures, considérées comme stables, qui ne recevraient plus que des correctifs améliorant la stabilité ou la sécurité (pour de plus amples informations, je vous conseil la lecture des deux billets de blog d’Allison Lortie, Gtk 4.0 is not Gtk 4 et Gtk 5.0 is not Gtk 5).

Après la sortie de GTK+ 4, qui ne devrait probablement pas avoir lieue avant 2018, une nouvelle version majeure sortirait approximativement tous les deux ans. Et entre chaque nouvelle version majeure, nous continuerions comme aujourd’hui de bénéficier de nouvelles versions mineures tous les six mois, qui apporteraient leur lot de nouveautés.

Mais c’est là que ça se gâte. Pour le moment, on semble se diriger vers un GTK+ 4 qui ne correspondrait pas à GTK+ 4.0. Et il en irait de même pour GTK+ 5 ou 6. En gros, durant les dix-huit premiers mois (ce qui correspond à trois versions mineures), les développeurs seraient libres d’ajouter de nouvelles fonctionnalités et de casser l’API autant qu’ils le souhaitent. Une fois le code stabilisé, il sera alors décidé que GTK+ 4.6 ou 4.8 pourra devenir le nouveau GTK+ 4.

GTK+ Hackfest 2016 (© Matthias Clasen)

À ce moment de l’article, vous ne pouvez vous empêcher de trouver ça idiot et de vous demander pourquoi ils ne travailleraient pas plutôt sur une branche de développement qui, une fois stabilisée, donnerait GTK+ 4.0, première version stable de cette nouvelle branche ?

De l’avis des développeurs, il semble y avoir deux publics, qui ont chacun des besoins différents. D’un côté des projets comme GNOME, qui souhaitent pouvoir bénéficier rapidement des dernières nouveautés sans avoir besoin d’attendre deux ans. Projets qui, de par leur taille, auront toujours la main d’œuvre nécessaire pour adapter les différentes applications aux éventuelles nouveautés ou autres cassures d’API. Et de l’autre, les développeurs d’applications tierces, qui préféreront plutôt se baser sur une version stable qui ne bougera plus, et ne nécessitera donc plus une maintenance incessante et régulière.

Maintenant, il faut savoir que les discussions ont toujours lieues et qu’aucune décision ne sera prise avant le prochain GUADEC, qui se tiendra cette année du 12 au 14 août en Allemagne. Il est donc possible que le versionnage change encore d’ici là. Mais une chose est sûre, de l’avis même des développeurs, des versions stables plus régulières devraient faciliter et accélérer le développement, ce qui devrait nous apporter plein de bonnes choses dans les années à venir.

Une inconnue demeure néanmoins. Combien de branches seront maintenues en parallèle ? Surtout quand on sait que GTK+ 2, qui en est actuellement à la version 2.24.30, est toujours maintenu, près de quinze ans après sa première apparition.