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.

Création du programme de stages GNOME

En plus de son investissement dans les programmes Google Summer of Code et Outreachy, la fondation GNOME vient d’annoncer la création d’un nouveau programme de stages propre au projet GNOME, aux objectifs bien plus complexes et stratégiques.

Pour reprendre l’annonce officielle, « l’objectif du programme de stages GNOME est d’amener le développement vers des sujets qui sont essentiels à la réalisation des objectifs de GNOME. Pour accomplir des tâches aussi importantes, les projets de génie logiciel et les projets non techniques sont les bienvenus, et tout le monde est encouragé à poser sa candidature. Puisque ces tâches sont considérées comme étant plus complexes que ce que l’on trouve dans les autres programmes de stages de la communauté du logiciel libre, les stages GNOME auront une allocation de 8000$ pour une période de trois mois. La fondation GNOME est désormais en mesure de réorienter les fonds vers des thèmes spécifiques qui peuvent être levés par le biais de campagnes et d’autres initiatives. »

Les premiers projets proposés sont axés autour de la sécurité et du respect de la vie privée, comme la protection contre les attaques par le biais de l’USB (en se basant sur USBGuard), la création d’une application pour la gestion des mots de passe et autres identifiants, un nouveau portail PipeWire, la création d’une session invité, facilité l’utilisation de matériel cryptographique tel que TPM ou pouvoir ajuster automatiquement les politiques de sécurité en fonction de la position géographique de l’utilisateur (domicile, travail, lieu public, conférence).

Pour plus d’informations, vous pouvez consulter la page du programme ou celle des différents projets.

Liste des projets acceptés pour le Google Summer of Code 2018

Cet été, 16 étudiants travailleront à l’amélioration de GNOME grâce au programme Google Summer of Code.

Les différents projets incluent la mise à jour automatique de Journaux quand de nouvelles entrées apparaissent dans l’historique des événements. La possibilité de modifier la vitesse d’une vidéo dans Pitivi, de réduire temporairement la résolution lors du montage et l’amélioration de son interface. Le portage de Fichiers en GTK+ 4. L’ajout de la consommation énergétique des applications et du matériel dans Utilisation. L’ajout de nombreuses fonctionnalités à l’application de messagerie Fractal (préférences utilisateur, amélioration de l’interface, internationalisation…). L’ajout de diverses améliorations à Jeux (tri de la liste des jeux par plateforme ou développeur, affichage de métadonnées pour les jeux (description, note, nombre de joueurs…), ainsi que la possibilité de sauvegarder des statistiques telles que le nombre d’heures jouées et si le jeu a été fini). L’ajout de fonctionnalités non précisées à l’application de messagerie Dino. L’amélioration des greffons Todo.txt et Todoist de To Do pour qu’ils soient utilisables en production. La réécriture du jeu Cinq ou plus en Vala et la modernisation du code pour une meilleure maintenabilité.

Notez qu’il ne s’agit que de la liste des projets qui ont été acceptés. Il n’y a aucune garantie sur le fait que les étudiants pourront mener leur projet à terme, et que la qualité du travail soit suffisamment bonne pour qu’il soit un inclus dans les différentes applications.

Rien ne dit que nous retrouverons donc toutes ces fonctionnalités dans la prochaine version de GNOME.

Test d’utilisabilité concernant GNOME et Debian

Durant l’événement Contribuez vos compétences à Debian, qui s’est déroulé à Paris du 13 au 14 mai 2017, des développeurs de la distribution Debian ont organisé une session de tests d’utilisabilité de GNOME 3.22, qui sera l’environnement par défaut de la future Debian 9 (Stretch).

Il a été demandé à un groupe de six personnes d’accomplir une série de tâches dans le gestionnaire de fichiers (télécharger et renommer un fichier, manipuler des dossiers, ajouter un signet, modifier les paramètres d’affichage), la logithèque (installer et désinstaller une application, trouver une application permettant de télécharger des fichiers par BitTorrent et l’installer, mettre à jour le système) ou les paramètres système (modifier l’arrière-plan, modifier les paramètres concernant les fichiers temporaires, modifier le lecteur vidéo par défaut, ajouter et supprimer des horloges mondiales).

Comme on peut le constater sur la carte de chaleur, la plupart des tâches ont été accomplies sans grande difficulté.

Carte de chaleur montrant la difficulté à accomplir certaines tâches

Le vert indique que le participant a pu accomplir la tâche avec peu ou aucune difficulté, le jaune qu’il a rencontré des difficultés importantes, le rouge qu’il a rencontré des difficultés extrêmes ou lorsque la tâche a été accomplie de manière erronée et enfin, le noir, que le participant n’a pas réussi à accomplir la tâche demandée.

Dans Fichiers, la principale difficulté fut l’ajout de signets.

Pour l’installation et la désinstallation d’applications, Logiciels est habituellement particulièrement simple. Mais dans le cas présent, manque de pot, les développeurs ont fourni des machines avec la version live CD de Debian et se sont rendu compte durant le test que cette dernière ne proposait pas la liste des paquets disponibles et que par conséquent, Logiciels ne pouvait proposer que les applications déjà installées (voir le bug #862560). À l’avenir, toujours penser à effectuer soi-même les différentes tâches demandées avant de débuter un test d’utilisabilité :D

Au sujet de la modification des paramètres concernant les fichiers temporaires ou la modification du lecteur vidéo par défaut, il est regrettable que les participants n’aient pas pensé à taper les mots-clés temporaire ou défaut dans la vue d’ensemble des activités, qui leur aurait proposé les outils de configuration adéquats.

Sinon, en passant par le Centre de contrôle, les réglages concernant les fichiers temporaires s’effectuent depuis les paramètres de confidentialité, et la modification du lecteur vidéo par défaut, dans le volet Détails puis Applications par défaut. Mais là, pour le coup, il faut reconnaître que Détails n’est absolument pas parlant.

Si vous souhaitez en apprendre plus sur les différents tests, les erreurs des participants ou leur cheminement, je vous invite à lire le billet de blog d’intrigeri.

Autre point important, aucun des participants n’a utilisé l’aide des différentes applications, ce qui est plutôt regrettable sachant qu’elle est plutôt complète, de bonne qualité, traduite en plusieurs langues et en adéquation avec la version en cours d’utilisation.

À l’arrivée, les tâches demandées n’étant pas particulièrement compliquées, ça montre le travail qu’il reste à accomplir pour rendre notre environnement encore plus simple d’utilisation.

Liste des projets acceptés pour le Google Summer of Code 2017

Google Summer of Code

Tous les ans, plutôt que de passer l’été à vendre des beignets sur la plage, Google permet à des étudiants de travailler sur des projets libres. Le fameux Google Summer of Code.

Cette année, 20 projets GNOME ont été acceptés :

  • Agenda : ajout de la prise en charge des tâches récurrentes.
  • Builder : trois étudiants travailleront sur l’environnement de développement du projet GNOME. Le premier sera en charge d’implémenter la navigation dans le code et de pouvoir effectuer des recherches globales de symboles. Un deuxième étudiant sera en charge de proposer de la documentation lors de l’écriture de code ou en cliquant sur une portion de code. Quant au dernier étudiant, il aura pour objectif d’améliorer le complètement automatique dans le but d’obtenir un fonctionnement plus proche de celui de Vim, pour trouver une correspondance après le mot ou le curseur.
  • Comptes en ligne : amélioration de la prise en charge de Nextcloud en proposant une liste d’hébergeurs si l’utilisateur ne dispose pas déjà de son propre compte. Amélioration de l’intégration au sein de Fichiers en ajoutant des options dans le menu contextuel ou en modifiant les icônes.
  • Disques : implémentation du redimensionnement et de la réparation des systèmes de fichiers.
  • Fichiers : réécriture de la gestion des entrées-sorties pour de meilleures performances. Amélioration de la recherche en utilisant toutes les possibilités offertes par Tracker, ce qui devrait offrir de nouveaux critères de recherche.
  • GJS : réécriture de certaines parties en Rust dans le but de réduire ou d’éliminer les fuites de mémoire et d’augmenter la sécurité.
  • GNOME Keysign : implémentation du transfert de clés par Bluetooth.
  • GNOME Shell : ajout de nouvelles fonctionnalités utiles et peaufinage de l’interface.
  • Jeux : possibilité de configurer clavier et manettes de jeu depuis l’application, ainsi que la prise en charge complète de la Nintendo DS et des différentes fonctionnalités inhérentes à cette console : double écran tactiles, fermeture de la console pour résoudre certains puzzles, rotation de l’écran…
  • Journaux : amélioration de la recherche, possibilité de filtrer les entrées redondantes ou de fournir des résultats au shell de GNOME.
  • Pitivi : mise en place d’un système de greffons et développement de plusieurs greffons qui seront fournis par défaut : console du développeur, marqueurs de la piste de montage et transitions automatiques. Ajout d’une interface utilisateur pour créer facilement un effet Ken Burns. Ajout d’une interface de correction de couleur utilisant trois roues chromatiques pour les ombres, les tons foncés et les tons clairs.
  • Mutter : suppression de la dépendance obligatoire à X11 pour les sessions Wayland.
  • Recettes : implémentation du partage de la liste de commissions vers l’application mobile Todoist.
  • To Do : implémentation de la prise en charge de Todoist.

Notez qu’il ne s’agit que de la liste des projets qui ont été acceptés. Il n’y a aucune garantie sur le fait que les étudiants pourront mener leur projet à terme, et que la qualité du travail soit suffisamment bonne pour qu’il soit un inclus dans les différentes applications.

Rien ne dit que nous retrouverons donc toutes ces fonctionnalités dans la prochaine version de GNOME.

Pixar aime bien GNOME :P

Ce n’est pas nouveau que de nombreuses entreprises ou organisations utilisent des distributions GNU/Linux sur leurs postes de travail, mais il s’agit généralement d’Ubuntu avec l’environnement Unity.

C’est donc avec un certain plaisir que nous avons pu remarquer lors du SIGGRAPH 2016 que Pixar utilisait des portables System76, sans doute équipés de CentOS 7 ou RHEL 7, avec l’environnement GNOME ^_^

Et oui, je sais, ça fait très fanboy comme comportement :D

Sinon, pour en revenir à la démonstration elle-même, il s’agit du projet Universal Scene Description, publié sous licence libre Apache 2.0, et dont les sources sont disponibles sur GitHub.

GUADEC 2016

Photo de groupe lors du GUADEC 2016
Crédit : Bin Li (CC BY-NC-SA 2.0)

Après la ville suédoise de Göteborg l’an passé, l’édition 2016 de la conférence européenne annuelle des utilisateurs et développeurs GNOME (GUADEC 2016), s’est tenue cette année du 12 au 17 août dans la ville allemande de Karlsruhe.

L’occasion pour les différents développeurs, traducteurs, designers… présents aux quatre coins du monde, de se rencontrer, d’assister à des conférences et des hackathons, ou plus simplement de discuter de l’avenir du projet.

Niveau conférences, on peut citer celles concernant la technologie Flatpak et ce que nous réserve son futur; le fonctionnement interne de Logiciels et les nouveautés à venir; les questions de sécurité et de vie privée; les mises à jour de sécurité de WebKit (Web, le navigateur du projet GNOME, utilisant WebKitGTK+); les graphes de flot de contrôle dans GNOME et GTK+; l’obtention d’une meilleure intégration des applications Qt; l’actuelle dépendance à des services tiers et le souhait d’une meilleure décentralisation; la présentation du film d’animation ZeMarmot entièrement réalisé avec des logiciels libres; la compilation d’applications GTK+ pour Microsoft Windows à l’aide de MinGW; les modification à apporter au projet GNOME pour qu’il puisse mieux fonctionner dans les pays ne bénéficiant pas de connexions Internet fiables; les ordinateurs portables et les tablettes commercialisés avec GNOME; la personnalisation de l’environnement pour les administrations… et bien plus encore.

Les différentes conférences ayant été filmées, vous pouvez retrouver les vidéos, en anglais et sans sous-titres, sur la chaîne YouTube officielle. Une page du wiki référence également quelques albums photos.

Jehan, qui était présent sur place avec Aryeom, a également publié un compte rendu en français.

De nombreux participants ont également blogué sur le sujet :

Rendez-vous l’an prochain à Manchester ;-)

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.