URL: https://linuxfr.org/news/gnome-3-28
Title: GNOME 3.28
Authors: thamieu
 antistress, liberforce, Oliver, Yves Bourguignon, Benoît Sibaud, Jehan, ptitjano, Davy Defaud, lejocelyn, ZeroHeure, Brndan, ff9097, yeKcim, Pazns, Bruno Michel, Dreammm, bubar🦥 et Nicolas Casanova
Date: 2017年09月20日T18:09:56+02:00
License: CC By-SA
Tags: gnome, gnome3, libreoffice, lennart_poettering, debian, fedora et lwn
Score: 78
GNOME a annoncé, mercredi 14 mars 2018, 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 CE 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.
----
[Notes de publication de GNOME 3.28](https://help.gnome.org/misc/release-notes/3.28/)
[Article précédent, à l’occasion de la 3.26](https://linuxfr.org/news/des-nouvelles-de-gnome-a-l-occasion-de-la-3-26)
----
![Photo de Chongqing, par Lennart Poettering](http://0pointer.de/public/chongqing/big/IMG_0536.jpg)
# GNOME Shell
## Des fenêtres sur mesure
Le code n’ayant été prêt que quelques jours [après la fenêtre de tir](https://feaneron.com/2017/09/13/gnome-3-26-is-great/) de 3.26, il a été livré dans une [3.26.1](https://feaneron.com/2017/10/03/improved-half-tiling-available-in-mutter-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’agrandit automatiquement pour occuper l’espace libéré !
![Redimensionnement des fenêtres, par feaneron](https://feaneron.files.wordpress.com/2017/06/captura-de-tela-de-2017年06月13日-00-04-53-e1497323173521.png)
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 ? Eh 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](https://wiki.gnome.org/GeorgesNeto/MinutesOfFeaneron/Tiling), et son développeur quelque peu [surmené](https://feaneron.com/2018/02/05/on-gnome-3-27-90-time-management-and-a-goodbye/) 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](https://wiki.gnome.org/Hackfests/UX2017). On vous recommande tout particulièrement l’[article de Cassidy Blaede](http://blog.system76.com/post/167747412318/gnome-ux-hackfest-2017), 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](https://github.com/gnome-design-team/london-ux2017-experiments/tree/master/lock-login). 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](https://raw.githubusercontent.com/gnome-design-team/london-ux2017-experiments/master/lock-login/GNOME_hackfest_0007_lock_exp_03.png)
## 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 trois 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_](https://csorianognome.wordpress.com/2014/12/12/nautilus-port-to-gaction-gmenu-and-popovers-penultimate-last-step/). 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.
Eh 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 vingt 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](https://csorianognome.wordpress.com/2016/08/31/nautilus-3-22-news-changes/) de Nautilus. À 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](https://csorianognome.wordpress.com/2017/12/21/nautilus-desktop-plans/), 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 à reclarifier les choses sur ce que cela allait entraîner en particulier [pour les utilisateurs d’Ubuntu](https://didrocks.fr/2018/01/23/welcome-to-the-ubuntu-bionic-age-nautilus-a-lts-and-desktop-icons/).
![« No Desktop Icons? », par Didier Roche](https://didrocks.fr/images/bionic-age/no-desktop-icons.png)
# 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](https://csorianognome.wordpress.com/2018/02/09/nautilus-team-grows-its-my-pleasure-to-welcome-ernestas-kulik-as-co-maintainer/)) ;
- *Photos* permet dorénavant l’importation 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](http://www.uajain.com/GNOME-Photos-happenings/)) ;
- 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](https://help.gnome.org/misc/release-notes/3.28/developers.html.fr), vous y verrez que le développement de _Builder_ a été, comme d’habitude, très actif (vous pouvez aussi parcourir [la catégorie _ad hoc_ du blogue de Christian Hergert](https://blogs.gnome.org/chergert/category/builder/)) !
# Développement
## Nouvelle forge : GitLab CE
Historiquement, le projet GNOME utilisait [_cgit_](https://git.gnome.org//browse/) et [Bugzilla](https://bugzilla.gnome.org/) pour héberger son code et suivre les remontées de bogues. Trouvant l’expérience utilisateur insatisfaisante, [une étude](https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure) a été conduite pour évaluer des outils alternatifs (GitLab CE et Phabricator) et la possibilité de les utiliser. C’est finalement GitLab CE qui a été retenue.
Un [programme pilote](
https://csorianognome.wordpress.com/2017/10/28/gitlab-initiative-small-explanation/) a été lancé pour vérifier que GitLab CE remplissait bien toutes les conditions nécessaires. Ce programme a consisté à migrer quelques applications volontaires sur une plate‐forme GitLab CE pour effectuer un test grandeur nature et récolter des retours d’expérience de la communauté. En parallèle, GNOME a travaillé de concert avec les équipes de GitLab CE pour résoudre les points bloquants et autres [problèmes](https://gitlab.gnome.org/Infrastructure/GitLab/issues/8).
Les retours ont été globalement très positifs. Il a donc été décidé [en décembre dernier](https://csorianognome.wordpress.com/2017/12/06/gitlab-update-moving-to-the-next-step/) 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](https://blogs.gnome.org/chergert/2018/01/15/musings-on-bug-trackers/)), et beaucoup d’autres [attendent](https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=migration+request). 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 CE](https://salsa.debian.org/). Rappelons que si les versions retenues par GNOME et Debian sont libres (version CE pour _Community Edition_), la société développe son modèle économique sur une stratégie OpenCore (vesion EE pour _Enterprise Edition_) : certaines fonctionnalités sont propriétaires. C’est pourquoi on ne s’étonnera pas de lire que la société GitLab a réalisé une [levée de fonds de vingt millions de dollars](https://about.gitlab.com/2017/10/09/gitlab-raises-20-million-to-complete-devops/), notamment auprès de GV (Google Ventures), moins de deux ans après la fermeture de [Google Code](https://code.google.com/archive/).
## Compilation avec Meson
Le logiciel [Meson](https://en.wikipedia.org/wiki/Meson_(software)) permet de simplifier et d’optimiser la compilation d’un projet, dans le même esprit que [CMake](https://fr.wikipedia.org/wiki/CMake) et les [Autotools](https://fr.wikipedia.org/wiki/Autotools). En 2016, la dépêche sur GNOME 3.22 parlait d’un [début de migration des Autotools vers Meson](https://linuxfr.org/news/gnome-3-22-karlsruhe-a-land-far-far-away#la-compilation-de-gstreamer-bient%C3%B4t-confi%C3%A9e-%C3%A0-meson-plut%C3%B4t-que-les-autotools). Le mouvement continue avec la [liste croissante des logiciels GNOME construits à l’aide de cet outil](https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting).
 
2017 a été une année très favorable à Meson avec les migrations de [GStreamer](http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html), [Tracker](https://samthursfield.wordpress.com/2017/05/22/tracker-%F0%9F%92%99-meson/), [GTK+](https://blog.gtk.org/tag/meson/), [xmlrpc-c](https://blogs.gnome.org/ignatenko/2016/12/17/meson-%e2%99%a5-xmlrpc-c/#more-269), et des débuts de migration chez [X.Org](https://anholt.livejournal.com/52972.html) et [Mesa](https://lwn.net/Articles/718287/). Au point que Christian Schaller, le responsable de l’équipe Red Hat en charge de l’environnement de bureau GNOME, [prédit](https://blogs.gnome.org/uraeus/2017/12/15/some-predictions-for-2018/) que Meson devrait devenir en 2018 le système de construction de la communauté GNU/Linux. Ce ne sont pas les développeurs d’Elementary qui vont lui [donner tort](https://medium.com/elementaryos/all-aboard-the-meson-future-hype-train-2b6c478b6b9e).
# Livraison
## Flatpak ouvre grand son portail
Si vous venez souvent sur _LinuxFr.org_, vous avez probablement déjà entendu parler de [Flatpak](https://flatpak.org/), ce moyen pour faciliter l’installation des applications sur l’ensemble des distributions. Bien qu’il soit présenté comme [communautaire](https://flatpak.org/about.html), vous savez peut‐être qu’il est conçu par Alex Larsson, travaillant pour Red Hat. Vous savez également que cette proposition est apparue à peu près à la même période que [Snap](https://snapcraft.io/) qui est, lui, porté par Canonical. Et que, de toute façon, [AppImage](https://appimage.org/) existe depuis bien plus longtemps et que l’on est en plein dans le _[[xkcd]]_ sur la [prolifération des normes](https://xkcd.com/927/) (que l’on n’affichera pas ici, parce que tout le monde l’a déjà lu 927 fois, pas vrai ?).
Eh 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](https://github.com/flatpak/flatpak/wiki/Portals). 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](http://docs.flatpak.org/fr/latest/_images/diagram.svg)
Suite à l’initiative de [J. Henstridge](https://github.com/jhenstridge) (aucun lien de parenté avec [Natasha Henstridge](https://fr.wikipedia.org/wiki/Natasha_Henstridge)) visant à faire fonctionner les portails avec les Snaps, Alex 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](https://github.com/flatpak/xdg-desktop-portal/pull/136).
## Une collection grandissante
Le site [Flathub](https://flathub.org/apps/) 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](https://conf-ng.jres.org/2015/document_revision_1702.html?download) 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 [bêta](https://beta.flathub.org/home), 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 d’information [_ici_](https://blogs.gnome.org/mcatanzaro/2017/12/17/epiphany-stable-flatpak-releases/)). 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 [_là_](https://blogs.gnome.org/mcatanzaro/2018/01/24/announcing-epiphany-technology-preview/)) !
## 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_](https://rpm-ostree.readthedocs.io/en/latest/)), 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, voir le [billet de blogue récent de Matthias Clasen](https://blogs.gnome.org/mclasen/2018/02/08/first-steps-with-fedora-atomic-workstation/) et le [Wiki Fedora](https://fedoraproject.org/wiki/Workstation/AtomicWorkstation) (la récente dépêche _Apports de Fedora à l’écosystème du logiciel libre_ [l’évoquait](https://linuxfr.org/news/apports-de-fedora-a-l-ecosysteme-du-logiciel-libre#fedora-atomic--cest-de-la-bombe) 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](https://linuxfr.org/news/librem-5-un-projet-de-telephone-mobile-libre-tournant-sous-gnu-linux), ce téléphone évolué dont les premiers visuels montraient une interface ressemblant furieusement à GNOME Shell. Et pour cause, [PureOS](https://pureos.net/), la distribution pour ordinateurs de bureau 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ć](https://puri.sm/wp-content/uploads/2018/01/peterk-artwork.jpg)
À 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](https://puri.sm/posts/gnome-and-kde-in-pureos-diversity-across-devices/) à 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 (que l’[on connaît bien ici](https://linuxfr.org/users/kekun)), 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 mobile entre les positions horizontale et verticale. L’idée est illustrée par l’auteur dans un [billet de blog](http://bytesgnomeschozo.blogspot.fr/2018/01/gtk-apps-on-phones.html), depuis complété par un [second billet](http://bytesgnomeschozo.blogspot.fr/2018/03/one-widget-to-adapt-them-all-and-to.html) faisant état de l’avancement de ce _widget_.
 
Évidemment, 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 étiquetés _design_](https://puri.sm/posts/tag/uxd/) qui laissent entrevoir comment pourrait être utilisée la version mobile de PureOS.
## Applications basées sur GTK+
Suite aux versions [5.4](https://linuxfr.org/news/libreoffice-5-4-5) et [6.0](https://linuxfr.org/news/sortie-de-libreoffice-6-0), la future version 6.1 de LibreOffice aura droit à des boîtes de dialogue en GTK+ 3 ! Le billet de blogue de Caolán McNamara nous présente [en images](https://caolanm.blogspot.fr/2018/03/native-gtk3-message-dialogs.html) ce changement bienvenu.
 
Jehan a récemment publié [une dépêche](https://linuxfr.org/news/les-dernieres-nouvelles-de-zemarmot) narrant le travail en cours sur _ZeMarmot_ et GIMP, notamment l’implémentation d’un système de débogage 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_](https://coaxion.net/blog/2017/10/dash-trick-mode-playback-in-gstreamer-fast-forwardrewind-without-saturating-your-network-and-cpu/) ou [_celle‐là_](https://coaxion.net/blog/2017/10/multi-threaded-raw-video-conversion-and-scaling-in-gstreamer/), par exemple.
 
Un client [Matrix](https://matrix.org/blog/posts/) vient de voir le jour : [Fractal](https://wiki.gnome.org/Apps/Fractal). Il est écrit en Rust et est, lui aussi, disponible en Flatpak.
![Fractal](https://wiki.gnome.org/Apps/Fractal?action=AttachFile&do=get&target=highlight3-figure.png)
## WebKitGTK+ dans les distributions
À l’occasion des versions [3.20](https://linuxfr.org/news/parution-de-gnome-3-20-delhi#s%C3%A9curit%C3%A9-dans-web) et [3.26](https://linuxfr.org/news/des-nouvelles-de-gnome-a-l-occasion-de-la-3-26#int%C3%A9gration-dans-les-distributions), 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](https://jeremy.bicha.net/2018/03/10/webkitgtk-debian-stretch-report/) (_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](https://wiki.gnome.org/ReleasePlanning/FeaturePlans), 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](https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4) (en anglais).
 
Envie de participer ? Rejoignez la communauté _LinuxFr.org_ dans l’[espace de rédaction](https://linuxfr.org/redaction) pour suivre le cycle de développement qui vient de s’ouvrir ; ou bien, rejoignez la [communauté GNOME](https://www.gnome.org/get-involved/) pour créer et présenter les fonctionnalités de demain !
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/gnome-3-28.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/gnome-3-28.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>