GNOME 3.28

GNOME a annoncé, mercredi 14 mars, la version 3.28 de son environnement de bureau, qu’elle a baptisé Chongqing en référence à la ville chinoise qui a accueilli le rassemblement GNOME Asie de 2017. Comme tous les six mois, nous profitons de la sortie de la dernière mouture pour parler un peu de ce qu’il s’est passé durant le dernier cycle de développement, dans GNOME et autour. On verra que c’est toute la chaîne d’approvisionnement des logiciels qui est en cours de mutation, puisque la communauté s’est officiellement dotée d’une instance Gitlab comme nouvelle forge logicielle, que la compilation de plusieurs briques importantes de GNOME est désormais confiée à Meson, et que Flatpak continue son bonhomme de chemin.

Photo de Chongqing, par Lennart Poettering

Sommaire

GNOME Shell

Des fenêtres sur mesure

Le code n’ayant été prêt que quelques jours après la fenêtre de tir de 3.26, il a été livré dans une 3.26.1. Nous n’avions donc pas pu parler de ce changement lors de notre précédent article.

Dans GNOME Shell, les fenêtres pouvaient être glissées vers les bords de l’écran pour n’en occuper que la moitié gauche ou la moitié droite. Pratique, mais assez limité. Maintenant, lorsque plusieurs fenêtres se répartissent la surface de l’écran, il est possible de les redimensionner simultanément. C’est-à-dire que lorsqu’on réduit l’espace occupé par une fenêtre, sa voisine s’aggrandit automatiquement pour occuper l’espace libéré !

Redimensionnement des fenêtres, par feaneron

Cela constitue une étape importante vers le “quarter tiling”, ou le redécoupage du bureau pour afficher quatre fenêtres en même temps. Cette fonctionnalité attendue de longue date est-t-elle dans GNOME 3.28 ? Hé bien non, et à moins de se sentir capable de l’implémenter, il faudra attendre encore un peu ! Cette fonctionnalité ne devrait pas voir le jour avant GNOME 3.30 si l’on en croit la page wiki dédiée, et son développeur quelque peu surmené a du s’accorder un peu de répit.

UX hackfest

Du 14 au 17 novembre dernier s’est tenu à Londres un petit évènement en comité réduit. Quelques développeurs et “UX designers” réunis autour de GNOME Shell ont donc pu travailler sur la vue d’ensemble des activités (“activities overview”), la gestion des fenêtres, ou encore l’accueil des utilisateurs lors du premier lancement du Shell. Parmi les participants figuraient notamment Allan Day (évidemment), Tobias Bernard, Robin Tafel (Endless) et Cassidy Blaede (Elementary, System76).

Si le sujet vous intéresse et que l’anglais ne vous fait pas peur, sachez qu’une page wiki pointe sur différentes ressources. On vous recommande tout particulièrement l’article de Cassidy Blaede, qui montre que des pistes de réflexion vraiment sympas mériteraient d’être développées, notamment du côté de l’écran de connexion. L’illustration ci-après n’est qu’une piste parmi d’autres, elle ne sera probablement jamais implémentée…

Travail expérimental sur l'écran de connexion, par Robin Tafel

Le Shell perd ses icônes

Héhé ! Il y a un troll récurrent une tradition avec GNOME c’est qu’on accuse toujours ses participants de retirer des fonctionnalités, sans jamais reconnaître les ajouts. On a avec Fichiers (autrefois connu sous le nom de Nautilus) un joli cas d’étude. On se souvient peut-être, il y a plus de 3 ans maintenant, que Carlos Soriano avait repris la maintenance de Nautilus, le navigateur de fichiers. Il avait très rapidement mis l’accent sur le nettoyage de code pour implémenter les maquettes des designers, comme à l’époque où il s’agissait de mettre en place les nouveaux menus et popovers. Depuis, chaque nouvelle version de Fichiers s’est avérée plus fonctionnelle et plus agréable que la précédente. En particulier, la fonctionnalité de renommage en masse des fichiers est déconcertante de facilité et d’efficacité. La gestion (extraction et compression) des archives aussi. Mais un changement n’a pas plu : le retrait de la gestion du bureau.

Hé oui. La gestion du bureau, c’est-à-dire la superposition d’icônes sur le fond d’écran lorsqu’aucune fenêtre n’est affichée, était confiée au navigateur de fichiers. Oui oui, même lorsque l’utilisateur n’avait pas demandé à lancer celui-ci, il fallait bien qu’il tourne s’il fallait afficher les icônes sur le bureau… Une fonctionnalité « historique » (presque aussi vieille que GNOME qui vient de fêter ses 20 ans…) qui rendait la gestion des vues très compliquée, si compliquée que Soriano l’avait pointée du doigt comme l’un des monstres de Nautilus. A l’époque de la 3.22 déjà, le mainteneur avait séparé cette partie du reste du code. Hélas cette tentative avait entraîné plus de problèmes qu’elle n’en avait résolu, et le développeur principal a dû annoncer en décembre la décision de ne plus prendre en charge cette fonctionnalité qui n’était de toute façon plus maintenue depuis belle lurette.

Dans son annonce, il a pris le temps de contextualiser, expliquer la problématique, présenter les alternatives et même réaliser un prototype d’extension pour GNOME Shell, cela n’a pas suffit à éviter quelques commentaires rageux. Didier Roche (Canonical) n’a pas manqué de rappeler ces éléments et a eu la délicatesse d’inviter Soriano a reclarifier les choses sur ce que cela allait entraîner en particulier pour les utilisateurs d’Ubuntu.

No Desktop Icons? Par Didier Roche

Applications

Pour les nouveautés des applications du bureau, nous vous invitons à parcourir les très bien faites notes de version.

Soulignons-en tout de même quelques unes :

  • Fichiers vous permet à présent de mettre en favoris des fichiers et des dossiers, qu’il pourra vous restituer ensuite d’un clic sur l’item correspondant du panneau latéral (profitons-en pour signaler l’intronisation d’un deuxième mainteneur pour Fichiers) ;
  • Photos permet dorénavant l’import de vos clichés depuis un média externe, ainsi que leur tri lors de l’importation (et bien d’autres choses que vous découvrirez en lisant ce billet de blogue) ;
  • L’arrivée d’une nouvelle application (en préversion) : Utilisation, qui rappellera le bon vieux Moniteur Système à certains d’entre vous.
  • le transfert de fichiers vers vos machines virtuelles par glisser-déposer fait son apparition dans Machines

N’oubliez pas d’aller consulter la page dédiée aux développeurs et administrateurs systèmes, vous y verrez que le développement de Builder a été comme d’habitude très actif (vous pouvez aussi parcourir aussi la catégorie ad hoc du blogue de Christian Hergert) !

Développement

Nouvelle Forge : Gitlab

Historiquement, le projet GNOME utilisait cgit et bugzilla pour héberger son code et suivre les remontées de bogues. Trouvant l’expérience utilisateur insatisfaisante, une étude a été conduite pour évaluer des outils alternatifs (Gitlab et Phabricator) et la possibilité de les utiliser. C’est finalement GitLab qui a été retenu.

Un programme pilote a été lancé pour vérifier que GitLab remplissait bien toutes les conditions nécessaires. Ce programme a consisté à migrer quelques applications volontaires sur une plateforme GitLab pour effectuer un test grandeur nature et récolter des retours d’expériences de la communauté. En parallèle, GNOME a travaillé de concert avec les équipes de GitLab pour résoudre les points bloquants et autres problèmes.

Les retours ont été globalement très positifs. Il a donc été décidé en décembre dernier d’accélérer la migration de tous les projets qui le souhaitaient. À l’heure d’écriture de ces lignes, une cinquantaine de projets ont déjà franchi le pas (ce qui était très facile, à en croire certains), et beaucoup d’autres attendent. Il est à noter que les scripts de migration permettent de migrer les rapports de bogue ouverts.

GNOME n’est pas le seul projet libre d’envergure à migrer ses outils. Debian a également mis en place sa propre instance gitlab. Rappelons que si les versions retenues par GNOME et Debian sont libres, la société développe son modèle économique sur une stratégie OpenCore : certaines fonctionnalités sont propriétaires. C’est pourquoi on ne s’étonnera pas de lire que Gitlab a réalisé une levée de fonds de 20 millions de dollars notamment auprès de GV (Google Ventures), moins de 2 ans après la fermeture de Google code.

Compilation avec Meson

Le logiciel Meson permet de simplifier et d’optimiser la compilation d’un projet, dans le même esprit que CMake et les autotools. En 2016, la dépêche sur GNOME 3.22 parlait d’un début de migration des autotools vers Meson. Le mouvement continue avec la liste croissante des logiciels GNOME construits à l’aide de cet outil.

2017 a été une année très favorable à Meson avec les migrations de GStreamer, tracker, GTK+, xmlrpc-c, et des débuts de migration chez Xorg et Mesa. Au point que Christian Schaller, le responsable de l’équipe Red Hat en charge de l’environnement de bureau GNOME, prédit que Meson devrait devenir en 2018 le système de construction de la communauté Linux. Ce ne sont pas les développeurs d’Elementary qui vont lui donner tort.

Livraison

Flatpak ouvre grand son portail

Si vous venez souvent sur LinuxFr.org, vous avez probablement déjà entendu parler de Flatpak, ce moyen pour faciliter l’installation des applications sur l’ensemble des distributions. Bien qu’il soit présenté comme communautaire, vous savez peut-être qu’il est conçu par Alex Larsson, travaillant pour RedHat. Vous savez également que cette proposition est apparue à peu près à la même période que le Snap, qui est lui porté par Canonical. Et que de toute façon AppImage existe depuis bien plus longtemps et que de toute façon on est en plein dans le xkcd sur la prolifération des normes (qu’on affichera pas ici parce que tout le monde l’a déjà lu 927 fois, pas vrai ?).

Hé bien sachez aujourd’hui que les développeurs de Snap et Flatpak ont réussi à s’entendre sur un truc ! Le truc en question ce sont les portails. En effet, les deux formats isolent les applications dans des bacs à sable dans lesquels elles n’ont pas accès à grand-chose. Les portails permettent aux applications isolées d’accéder à des ressources situées en-dehors de leur bac à sable.

Schéma de fonctionnement des flatpak

Suite à l’initiative de J. Henstridge (aucun lien de parenté avec N. Henstridge) visant à faire fonctionner les portails avec les snaps, A. Larsson a procédé à quelques changements pour lui faciliter le boulot. Il a implémenté le “document portal” dans xdg-desktop-portal plutôt que dans Flatpak lui-même, ce qui permet à Snap (et à tout autre outil) de s’appuyer dessus. L’utilité ? Les développeurs d’applications pourront retrouver cette fonctionnalité dans les deux formats, en ciblant une seule API. Les discussions entre Henstridge et Larsson sont sur Github.

Une collection grandissante

Le site Flathub propose d’héberger les applications disponibles sous le format Flatpak. Il accueille un peu plus de 200 applications pour le moment, dont certaines sont développées par des lecteurs assidus de LinuxFr.org ! À noter que Flatpak a été conçu pour être décentralisé (il s’agit d’un système de classe 4 dirait sans doute Stéphane Bortzmeyer), c’est-à-dire qu’il est possible d’utiliser d’autres dépôts que Flathub pour y puiser ses flatpak, voire de proposer ses propres dépôts. Si l’interface de Flathub est quelque peu rudimentaire, on remarquera qu’une nouvelle version du site est en beta, et elle n’est pas sans rappeler le gestionnaire de Logiciels de GNOME.

Parmi les nouveaux venus, on trouve par exemple GIMP, dont la sortie stable est officiellement distribuée sur Flathub. Web (alias Epiphany) est également disponible. Cela résout au passage le problème de sécurité (dont nous nous sommes fait l’écho dans les précédentes dépêches) lié à l’inclusion de versions obsolètes de WebKitGTK+, puisque vous aurez ainsi les dernières versions stables d’Epiphany et de WebKitGTK+ (plus ici). Bonus : vous pouvez aussi tester la dernière version de développement sans altérer votre système, avec le paquet Flatpak Epiphany Technology Preview (plus ) !

Une distribution basée sur Flatpak ? Fedora Atomic Workstation

Actuellement les distributions embarquent indifféremment l’ensemble de leurs composants logiciels dans des paquets, qui peuvent dépendre les uns des autres. L’idée derrière le projet Atomic est de fournir le cœur du système d’exploitation sous forme d’images immuables, que l’on pourrait toutefois mettre à jour. On peut se représenter cette mise à jour comme une couche qu’on viendrait superposer à l’image de base. Si un problème venait à être rencontré sur l’une de ces couches, il resterait possible de démarrer sur la précédente, sans le risque d’être bloqué par l’endommagement de la distribution. Ce principe est rendu possible par rpm-ostree), et ça peut être utilisé pour générer des images au format Docker.

Plusieurs déclinaisons de Fedora Atomic existent, dont une dédiée aux postes de travail. En plus de rpm-ostree, Fedora Atomic Workstation repose sur Flatpak pour les applications. Ces dernières reçoivent les mises à jour au fur et à mesure qu’elles sont poussées directement par leurs développeurs (rompant avec les pratiques existant jusqu’ici, selon lesquelles chaque distribution décide de pousser ou non les mises à jour une fois que les développeurs les ont publiées). Bref, applications et système d’exploitation peuvent être mis à jour indépendamment.

Pour en savoir plus, v. le billet de blogue récent de Matthias Clasen et le Wiki Fedora (la récente dépêche « Apports de Fedora à l’écosystème du Logiciel Libre » l’évoquait aussi).

Autour de GNOME

Vers les mobiles ?

On se souvient de la campagne lancée récemment par Purism pour financer le développement du Librem 5, ce smartphone dont les premiers visuels montraient une interface ressemblant furieusement à GNOME Shell. Et pour cause, PureOS, la distribution pour ordinateurs de bureaux livrée avec les Librem 13 et Librem 15, est conçue autour de GNOME.

Concept de Shell pour le Librem 5, par Peter Kolaković

A noter que suite à l’annonce du Librem 5, KDE avait assuré Purism de son soutien. La société semble donc décidée à aider les uns et les autres à faire avancer leur environnement sur le Librem 5, quoiqu’elle investira dans les développements susceptibles de faire advenir un GNOME mobile.

Si voir GNOME débouler dans les poches de tout un chacun est encore un rêve lointain, des progrès sont à signaler. Purism a recruté Adrien Plazas (qu’on connaît bien ici), lequel a commencé à bosser sur un nouveau widget destiné à permettre aux applications Gtk+ de s’adapter aux différentes tailles d’écran de manière dynamique. C’est typiquement utile lorsqu’on bascule un smartphone entre les positions horizontale et verticale. L’idée est illustrée par l’auteur dans un billet de blog, depuis complété par un second billet faisant état de l’avancement de ce widget.

Evidemment, tout cela n’est pas qu’une affaire de code dans Gtk. Vous pouvez vous référer au blog de Purism pour suivre l’avancement du projet, et parcourir en particulier les billets étiquettés design qui laissent entrevoir comment pourrait être utilisée la version mobile de PureOS.

Applications basées sur GTK+

Suite aux versions 5.4 et 6.0, la future version 6.1 de LibreOffice aura droit à des boites de dialogue en GTK+3 ! Le billet de blogue de Caolán McNamara nous présente en images ce changement bienvenu.

Jehan a récemment publié une dépêche narrant le travail en cours sur ZeMarmot et GIMP, notamment l’implémentation d’un système de débug pour ce dernier, dont le but est « d’encourager les gens à nous remonter les erreurs (le programme ne remonte pas les erreurs automatiquement, mais inclut un texte expliquant le processus et permettant de copier toutes les infos utiles d’un seul clic) ».

À noter par ailleurs que Pitivi, qui s’appuie sur GStreamer pour manipuler les flux audio/vidéo, bénéficie ipso facto de toutes les améliorations apportées au fur et à mesure à ce dernier par ses développeurs (dont ceux-là même qui développent Pitivi !), comme celle-ci ou celle-là par exemple.

Un client Matrix vient de voir le jour : Fractal. Il est écrit en Rust, et est lui aussi disponible en flatpak.

Fractal

WebkitGtk+ dans les distributions

À l’occasion des versions 3.20 et 3.26, Michael Catanzaro avait fait le point sur la sécurité des distributions, à travers le prisme des versions (obsolètes ou à jour) de WebKitGTK+ qu’elles embarquaient. En effet, ce composant critique se retrouve au cœur d’un certain nombre de logiciels du bureau. Jeremy Bicha prend le relais sur cette version, en faisant le bilan cette fois de la dernière version stable de Debian : reçoit-elle bien les mises à jour de sécurité de WebKitGTK+ ? Le bilan dans cet article (spoiler : c’est mieux mais pas parfait).

Et la suite ?

Voilà pour ce petit récapitulatif de ce qu’il s’est passé en coulisses ces six derniers mois. S’il n’y a pas vraiment de changement majeur côté utilisateur, on a vu que GNOME était dans une bonne dynamique, et continuait d’entretenir des relations qu’on espère très constructives, avec les anciens qui ont pignon sur rue (Ubuntu et Fedora), comme avec les plus récents qui continuent de se développer (Elementary, Endless, Purism…).

On peut espérer que les nouveaux outils dont se dote GNOME faciliteront la participation de nouveaux contributeurs pour les versions à venir. Les changements qui devraient avoir lieu avec la 3.30 n’ont pas encore été décidés, mais on peut s’attendre à de nouvelles améliorations côté Flatpak (notamment du côté des portails, maintenant que les Snap peuvent s’appuyer dessus). Le gestionnaire de fichiers, débarrassé de ses poids morts, va pouvoir intégrer de nouveaux widgets.

À plus long terme, une nouvelle version majeure GNOME 4 devrait débarquer afin de profiter pleinement des possibilités de Wayland. En fait, GNOME 3 a été conçu avec X11 en tête, et aujourd’hui, la prise en charge simultanée de Wayland et X11 rend le code inutilement complexe. Pour plus de détails, la page wiki GNOME Shell 4 (en anglais).

Envie de participer ? Rejoignez la communauté LinuxFr.org dans l’espace de rédaction pour suivre le cycle de développement qui vient de s’ouvrir, ou bien rejoignez la communauté GNOME pour créer et présenter les fonctionnalités de demain !

Lire les commentaires

(Source: LinuxFr.org : les dépêches)
Logo