On ne présente plus GNOME, l’environnement de bureau libre (depuis toujours), sexy (depuis la série 3.x), ergonomique (selon les points de vue), personnalisable (non, là, je plaisante, en revanche) et, dorénavant, à la pointe de la technique !

GNOME 3.22, nom de code Karlsruhe, est sorti le mercredi 21 septembre 2016, avec, sous le capot, rien de moins qu’une révolution…

La dernière version de GNOME est le résultat de six mois de développement dont 22 980 changements effectués par approximativement 775 contributeurs.

Sommaire

Général

Wayland, Wayland, Wayland !

Le choix de faire reposer par défaut GNOME sur Wayland a été différé à de nombreuses reprises… Le travail d’intégration est achevé et GNOME-Wayland est à présent comparable en termes de fonctionnalités à GNOME-X11. Ceci sans compter les bonus apportés par l’implémentation du protocole Wayland en termes de finition, de sécurité et même d’efficacité énergétique, ni les nouvelles possibilités qui s’ouvrent aux développeurs !

Périphériques d’entrée

Ces derniers mois ont vu arriver la prise en charge des tablettes graphiques par GTK+ sous Wayland (cf. ce billet de blogue), ce qui fut une des grosses raisons du retard de Wayland par défaut. En effet, si Wayland est probablement prêt à 99 % (statistiques sorties du chapeau), comme toujours, ce sont les détails qui bloquent. Bien qu’une majeure partie de la population utilisera essentiellement souris et clavier, sortir un système d’exploitation sans prise en charge de périphériques d’entrée avancés n’est pas possible de nos jours. C’est ainsi que libinput a annoncé successivement les versions 1.3.0 et 1.4.0 à quelques mois d’intervalle. Cette dernière version donne à son mainteneur l’occasion de jeter un œil en arrière pour mesurer le chemin parcouru.

Parmi les apports intéressants de Wayland, nous pouvons noter la gestion de pointeurs multiples : chaque périphérique de pointage est indépendant avec son propre pointeur (et même une icône de pointeur différente), contrairement à X où tous les périphériques se partageaient un pointeur unique. Ainsi, une souris et une tablette affichent deux pointeurs indépendants simultanément. On pourrait donc imaginer de nouvelles manières de travailler où un artiste pourrait dessiner avec un stylo à la main, et cliquer sur des boutons de l’autre main. On pourrait même avoir deux stylos numériques et dessiner simultanément (comme si vous dessiniez avec deux pinceaux en même temps, chacun pouvant avoir une texture, couleur et brosse différentes), ce qui est actuellement impossible. Ce type de fonctionnalité ouvre de nouvelles perspectives pour l’art numérique, mais aussi au niveau de l’interaction homme‐machine. Bien sûr, cela nécessite que les applications qui souhaitent tirer avantage de ceci adaptent leur code.

Mais quand on parle d’avancée dans les périphériques d’entrée, on parle notamment de tablettes graphiques, car ce sont des périphériques très polyvalents. Les souris, les claviers, etc., ce type de périphériques est plutôt bien supporté depuis longtemps et, même s’ils peuvent profiter de quelques touches un peu hors norme, ce sont généralement des fonctionnalités bien définies. C’est d’un ennui !

Les tablettes graphiques, en revanche, ont cette particularité qu’elles sont fournies de boutons génériques, c’est‐à‐dire qui n’ont pas de fonction par conception, à charge de l’utilisateur de les configurer. C’est ainsi que Carlos Garnacho explique l’amélioration de la prise en charge de ces boutons dans Wayland : plutôt qu’associer seulement une combinaison de type « touche clavier » (ex : ctrl + lettre ), il est désormais également possible d’associer des actions (donc une fonction sémantique). Mais encore mieux, les applications seront capables de configurer les boutons, un peu comme des profils applicatifs. Un artiste pourra ainsi configurer un bouton pour lancer une action particulière dans GIMP, par exemple un effet souvent utilisé, alors que dans Inkscape, ce même bouton pourra avoir une toute autre fonction. Cela nécessitera, bien sûr, une prise en charge au niveau du code des applications intéressées par ce type de fonctionnalité, qui sont donc probablement avant tout les applications de création graphique (davantage susceptibles d’avoir des utilisateurs possédant ce type de périphériques).



Mutter

Mutter aussi a été optimisé durant ce cycle de développement : amélioration du copier‐coller entre les applications X11 et les applications Wayland natives. Meilleure gestion du multi‐écran sous Wayland…

Applications tournant nativement

Outre les applications au cœur de GNOME, citons‐en quelques autres tournant nativement sous Wayland : LibreOffice, à partir de la version 5.0 (quelques finitions peuvent rester nécessaires ici ou là) ou encore Pitivi à partir de la version 0.95.

Rappelons également que les applications non encore converties à Wayland — par exemple, Firefox (ticket 635134) et GIMP (qui doit attendre le portage vers la version 3 de GTK+) — tournent néanmoins parfaitement et fluidement dans une session Wayland de GNOME, via le procédé XWayland.

Enfin, nous savons déjà que Fedora 25, par exemple, activera Wayland par défaut. Ainsi, RedHat tient une liste à jour de ce qui ne marche pas encore, mais également de ce qu’il reste à faire pour que certains outils puissent continuer à marcher sur Wayland avec GNOME.

Paramètres

Le centre de paramétrage est en train de changer de design avec une barre latérale de navigation où sont listées les paramétrages par catégorie avec leurs icônes et descriptions. Cette barre latérale redimensionnable est placée sur la gauche de la fenêtre.

L’ancienne vue est toujours celle par défaut. N’importe qui peut donc la lancer avec gnome-control-center-alt . À vous de tester et de remonter ce qui ne va pas !

Shell

meilleure prise en charge de Wayland ;

implémentation du système de permissions qui demandera à l’utilisateur s’il souhaite partager sa géolocalisation ou autoriser l’accès à certains périphériques (webcam, microphone…) pour les applications isolées qui en feront la demande ;

plusieurs dizaines de corrections de bogues.

Applications

Des fonctionnalités pour utilisateurs avancés font leur apparition dans cette version, comme la possibilité de renommer les fichiers en masse dans Fichiers (qui rattrape Thunar, son équivalent Xfce, sur ce point) ou d’éditer les méta‐données de vos fichiers musicaux via Musique. Ces fonctionnalités ont été implémentées par des étudiants du GSoC 2016, respectivement Alexandru Pandelea [blogue] et Saiful B. Khan [blogue].

Logiciels

gestion des applications Flatpak et Snap ;

prise en charge des extensions GNOME Shell ;

prise en charge initiale de Steam ;

les boîtes de dialogues pour la mise à niveau du système d’exploitation ont été retravaillées ;

l’information concernant la taille des paquets est désormais séparée en deux : la taille à télécharger et celle nécessaire pour l’installation ;

ajout d’un bouton d’annulation et d’informations de progression sur la page de détails ;

l’origine d’un paquet est désormais indiquée quand ce dernier est disponible depuis plusieurs sources différentes ;

prise en charge des liens appstream:// ;

; ajout d’informations concernant les applications isolées.

Agenda

L’agenda a été encore peaufiné, avec une gestion des alarmes, le changement possible de mois par raccourci clavier, une vue de tous les évènements du mois en cliquant sur le nom du mois, la prise en charge du glisser‐déposer…



Fichiers

Renommage en masse

Nautilus se dote d’un outil de renommage en masse de fichiers qui permet de faire du « rechercher et remplacer », mais également d’utiliser un patron prédéfini. Ce patron peut utiliser les étiquettes (tags) des fichiers musicaux.

À noter que les conflits sont surlignés en jaune par sécurité.

Fichiers compressés

L’ouverture des fichiers compressés s’est toujours faite avec un outil tiers, comme file-roller. Ceci empêchait de gérer la progression de la décompression au sein de Nautilus (mais également l’annulation, la répétition et la décompression en arrière‐plan en fermant la fenêtre), une bibliothèque a donc été mise en place pour ça : gnome-autoar.

Nautilus gère maintenant la création d’archives et leur décompression. Cette nouvelle bibliothèque permettra à d’autres applications, comme Evolution ou Epiphany, de gérer les archives directement.

Le comportement par défaut est de décompresser l’archive sélectionnée avec un double clic, mais une option dans les préférences permet de désactiver ce choix si besoin est.

Autres

Le menu de droite s’améliore, pour s’inspirer un peu de Firefox, par exemple dans la gestion du zoom.

La gestion du bureau est maintenant séparée de Nautilus pour plus de facilité de travail.

Cartes

Cartes utilise désormais Mapbox. Plutôt que de passer par un serveur mandataire (proxy) pour éviter une nouvelle interruption de service en cas de changement de fournisseur de tuiles, un fichier service.json est désormais téléchargé depuis les serveurs de GNOME pour savoir quel fournisseur de tuiles utiliser directement, ce qui rend l’affichage bien plus rapide.

Enfin, le « rebouclage horizontal » de la carte pour pouvoir faire le tour de la planète est maintenant là.

Jeux

Jeux est une jeune application GNOME pour présenter les jeux stockés dans votre ordinateur, qu’il s’agisse de jeux installés (natifs, Steam), de jeux à part (comme ceux utilisant l’infrastructure LÖVE) ou même de jeux à émuler (ROM et images disque). Dans le cas de ces derniers, Jeux se charge de les lancer dans sa propre fenêtre, faisant ainsi office de frontal pour émulateur basé sur Libretro.

Cette version 3.22 comporte pas mal de nouveautés majeures :

prise en charge des manettes de jeu ;

prise en charge du plein écran ;

prise en charge des jeux PlayStation pour l'émulation ;

téléchargement des pochettes de jeu pour la plupart des consoles (les pochettes sont récupérées depuis TheGamesDB.net pour les jeux consoles et le magasin Steam pour les jeux Steam),

affichage des jeux Atari 2600, Atari 7800, NEC CD-ROM² et Mega-CD ;

ajout d’icônes pour LÖVE et Nintendo DS.

Les détails figurent dans l’annonce de la sortie sur le blog d’Adrien Plazas.

Machines

L’outil de gestion des machines virtuelles présente les nouveautés suivantes :

ajout d’une option de clonage ;

l’ordre d’affichage des différentes machines virtuelles est préservé d’une session à l’autre ;

les noms d’hôte n’utilisent plus de caractères qui poseraient problème sous Microsoft Windows ;

les nouvelles machines virtuelles n’exposent plus la connexion SPICE à tous les utilisateurs ;

prise en charge des adresses URL SPICE spice+unix ;

ajout d’une action « redémarrer » et suppression de l’action « pause » dans le menu contextuel du mode Affichage.

Web

Le navigateur par défaut prend maintenant en charge le « coller et aller » (permettant de rendre directement à la page dont l’adresse est dans la presse‐papiers), déjà présent sous Firefox par exemple. La nouvelle fenêtre des raccourcis clavier fait maintenant son arrivée. Enfin, il est maintenant possible de dupliquer un onglet.

Musique

Certains auront noté que les performances de Musique n’étaient pas extraordinaires, mais c’est maintenant du passé.

Enfin, tout comme Web, Musique implémente également la page des raccourcis clavier.

Photos

Une prise en charge expérimentale du partage de photos (courrier électronique, Bluetooth, Google, Flickr…) fait son entrée, accompagnée de la possibilité d’annuler toutes les modifications effectuées sur une photo. Vous pouvez désormais envoyer vos photos dans les nuages directement.

Les fichiers GIF étant mal pris en charge (les fichiers GIF animés ne le sont pas toujours), ces derniers ne sont plus affichés pour le moment.

Documents

Documents vous permet maintenant de lire les fichiers au format EPUB (dans Books) et, pourquoi pas, en plein écran avec une barre d’outils sombre !

Évolution

Évolution vient juste de changer son moteur de rendu pour passer de Webkit 1 à Webkit 2 pour l’affichage des courriels. C’est un changement qui a pris du temps, mais qui a permis de résoudre plusieurs dizaines de bogues et d’apporter diverses améliorations.

Développeurs

Builder

Builder se refait une beauté :

nouveau système de recherche et de remplacement ;

nouvelle barre de compilation qui fournit des informations sur la configuration, la branche du système de gestion de versions et autres informations importantes ;

un nouvel outil pour le profilage de code basé sur Sysprof ;

amélioration des modèles de projets ;

ajout d’une interface de configuration des logiciels de gestion de versions ;

amélioration de la prise en charge de Vim ;

nouveau greffon de gestion des couleurs ;

amélioration de l’interface concernant la commande git clone , le sélecteur de fichiers ou l’assistant ;

, le sélecteur de fichiers ou l’assistant ; nouvelle icône.

Flatpak

Flatpak (anciennement xdg-app). Une sortie a eu lieu le 21 juin 2016.



Rappelons brièvement pourquoi cette nouvelle technologie fait autant de bruit : Flatpak devrait permettre aux Linuxiens d’installer l’application de leur choix sans se soucier de leur distribution, de la version de celle‐ci ou même des dépendances requises. En intégrant Flatpak à Logiciels (cf. plus haut), GNOME veut rendre son usage aussi simple que l’est déjà celui des logiciels distribués via APT ou RPM.

Une page dédiée recense quelques dépôts Flatpak disponibles : un dépôt gnome-apps pour les applications GNOME en version stable, un dépôt gnome-nightly-apps pour les applications GNOME en version nightly, un dépôt nightly-graphics d’outils de création graphique non liés à un environnement de bureau particulier et également en version nightly (tels que Darktable, GIMP, Inkscape et MyPaint) et enfin des dépôts pour LibreOffice, Telegram ou Pitivi.

À défaut de bundle pour le moment, un script préparé par un développeur de Red Hat permet de compiler Firefox depuis sa branche master, puis de le lancer et de le mettre à jour facilement en tant qu’application Flatpak.

Flatpak est disponible sur la plupart des distributions GNU/Linux courantes. Debian, parmi d’autres distributions, est prête.

Glib

En bref :

refonte de l’API de journalisation pour supporter les champs clef‐valeur structurés dans les journaux ;

ajout de la gestion du transfert de ces derniers au service systemd-journald ;

les sorties basées sur stdio bénéficient désormais de couleurs ;

bénéficient désormais de couleurs ; réorganisation de l’infrastructure de journalisation autour d’une fonction writer pour laquelle les applications spécifient leur stratégie de journalisation et dépréciation des gestionnaires de journaux en faveur de ce dernier, afin d’éliminer l’ambiguïté sur où et comment prendre en charge les journaux ainsi que les conflits entre gestionnaires de journaux ;

pour laquelle les applications spécifient leur stratégie de journalisation et dépréciation des gestionnaires de journaux en faveur de ce dernier, afin d’éliminer l’ambiguïté sur où et comment prendre en charge les journaux ainsi que les conflits entre gestionnaires de journaux ; d’autres fonctionnalités encore de l’infrastructure de journalisation sont présentées dans une API publique, laissant libres les applications de choisir entre différentes stratégies, allant de celle par défaut de la GLib à une personnalisation complète ;

les tests unitaires des messages de journal sont maintenant plus flexibles, car on peut les faire dans une fonction writer personnalisée plutôt qu’avec des fonctions internes à GLib (limitant, car imposant un ordre strict des vérifications de messages) ;

personnalisée plutôt qu’avec des fonctions internes à GLib (limitant, car imposant un ordre strict des vérifications de messages) ; la journalisation structurée simplifie l’implémentation de procédés de journalisation plus puissants, et devrait entraîner une moindre confusion sur les conflits entre les gestionnaires de journaux des différentes bibliothèques ;

facilitation de l’inclusion de plus de métadonnées dans les messages journaux, comme les identifiants de message (comme avec journald : https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html) ;

utilisation de journald si actif.

GTK+

Coup d’œil dans le rétro

Vous pouvez regarder la conférence (en anglais) GTK: Are we in the future, yet?, donnée au dernier GUADEC par Emmanuele Bassi, qui revient notamment sur l’évolution de GTK+ au cours de ces vingt dernières années.

Nouveautés de GTK+ 3.22

Nous attendions l’avènement de GTK Scene Kit (GSK) pour cette version, mais ce sera finalement pour la prochaine, autrement dit GTK+ 4.0. Nous en reparlerons donc à cette occasion. En attendant, les plus impatients d’entre vous pourront suivre (en anglais) le travail en cours sur le blogue d’Emmanuele Bassi [feuille de route de GTK+].

GTK+ 4.0 en approche !

Insaisissable GTK+ (= le problème)

Commençons par un résumé du feuilleton exposant le problème.

Ceux qui lisent LinuxFr.org le savent bien : le thémage avec le CSS a reçu une refonte majeure dans la précédente version de GTK+. Vers avril/mai, certains ont publiquement râlé en découvrant après coup que leurs applications ne se comportaient soudainement plus comme prévu, et divers échanges ont suivis. L’occasion de poser, une fois de plus, la question de la stabilité des interfaces de programmation de GTK+, spécialement de la série 3.x…

Hasard ou coïncidence, il a été décidé mi‐mai de réactiver le blogue relatif au développement de GTK+. De fait, celui‐ci est alimenté avec talent par Emmanuele Bassi et permet de suivre, semaine après semaine, l’actualité du développement de GTK+.

Vous avez dit Less‐than‐perfect API stability ?

Reconnaissant (par euphémisme interposé) le problème posé par le manque de stabilité de l’API de GTK+ 3, mais soulignant dans le même temps l’inconvénient que créerait un engagement de stabilité à long terme de cette dernière (qui risquerait de bloquer les évolutions futures nécessaires de la bibliothèque), les développeurs réunis au GTK Hackfest de Toronto mi‐juin ont proposé un plan qui semblait alors assez peu lisible (voir certains billets de blogue : “Gtk 4.0 is not Gtk 4”, “Gtk 5.0 is not Gtk 5”, GTK versioning and distributions, Dispatches from the GTK+ hackfest, Gtk+ Versioning, Long term support for GTK+…). Les diverses propositions (résumées sur une page de wiki) ont provoquées beaucoup de discussions et, bien sûr, du troll en pagaille, parfois virulent.

Tout est bien qui finit bien (du moins, espérons‐le)

Le consensus final est cependant bien plus simple et tout à fait compréhensible (car plus proche de la gestion de versions sémantique à laquelle les gens sont habitués). Tous les deux ou trois ans, une nouvelle version majeure stable sortira, ce qui implique un gel des fonctionnalités existantes (API stable). Bien sûr, des versions mineures stables pourront ajouter des widgets ou mettre à jour des implémentations, mais rien de transcendantal et, en particulier, il n’y aura pas de nouvelles fonctionnalités, ni de changement de thèmes ou d’API. Chaque version stable sera maintenue pour au moins trois ans (avec des corrections de bogues mettant à jour la micro‐version) et les développeurs d’applications tierces sont appelés à utiliser cette branche stable faite pour ne plus casser les applications. Exceptionnellement, la première version stable est GTK+ 3.22, car c’est une étape de transition, mais les versions stables ultérieures seront 4.0, puis 5.0, 6.0, etc.

Parallèlement à chaque sortie d’une nouvelle majeure stable, une nouvelle branche numérotée x.90 deviendra la nouvelle branche de développement. De cette branche éclora tous les six mois une version de développement. Ces versions pourront casser l’API, les thèmes, etc. Bien sûr, cela ne signifie pas que l’API sera cassée à chaque fois. Les développeurs GTK+ éviteront au maximum de casser le fonctionnement existant ; et, les rares fois où ils le feront, ils communiqueront dessus. En d’autres termes, cette branche de développement suivra la logique de développement actuelle de GTK+ 3.

Les développeurs d’applications tierces ne sont pas encouragés à utiliser ces versions (mais peuvent le faire, en acceptant le prix d’un travail de maintenance plus élevé). En revanche, on s’attend à ce que les applications core du projet GNOME, bien plus proches de GTK+ et de ses évolutions, se basent sur ces versions de développement et profitent ainsi des dernières nouveautés.

Tout cela peut mieux se comprendre par ce schéma d’exemple :

GStreamer

Jusqu’à présent le projet GStreamer utilisait la suite d’outils de compilation du projet GNU nommée Autotools, créée dans les années 80.

Nirbheek Chauhan et Tim‐Philipp Müller, pour le compte de Centricular, travaillent depuis quelques mois à utiliser un autre outil : Meson. Celui‐ci s’avère prometteur en ce qu’il permet de raccourcir drastiquement le temps de compilation : d’un facteur 2,5 sur GNU/Linux et d’un facteur 10 sur Windows ! Les tests se poursuivent sur l’ensemble des plates‐formes prises en charge par GStreamer : GNU/Linux, Mac OS X, Windows, iOS et Android.

Dans son billet, Nirbheek Chauhan semble aussi enthousiaste à l’égard de Meson que dépité à l’égard d’Autotools qu’il évoque en ces termes : « Appeler Autotools le X.Org des outils de compilation relève de la flatterie. C’est juste un outil horrible. Nous devons vraiment consacrer du temps à trouver quelque chose qui travaille pour nous plutôt que contre nous. »

Emmanuele Bassi y est également allé de son rapport d’expérience, et Pitivi 0.97 a sauté le pas.

Vous pouvez regarder la conférence donnée au dernier GUADEC sur le sujet par Nirbheek Chauhan.

Oxydation de GStreamer

Décidément la rouille (rust, en anglais) corrode tout : après Firefox, voici venu le tour de GStreamer !

Sebastian Dröge (alias slomo) (Centricular), à l’occasion du GStreamer Spring Hackfest 2016, a travaillé avec Luis de Bethencourt (Samsung) à permettre de lier le code C de GStreamer avec du code Rust (lire ce billet). Selon lui, dans un premier temps, des composants comme les analyseurs et les (dé)multiplexeurs gagneraient à être écrits en Rust compte tenu de leur complexité et de leur exposition à des données de tout genre et de toute provenance (parfois non garantie). Plus tard, des parts plus importantes du code de GStreamer pourraient également être réécrites en Rust.

Intégration dans les distributions

GNOME 3.22 sera intégré dans Fedora 25 prévue pour novembre 2016, Arch Linux, Ubuntu GNOME 17.04, Debian (cette version devrait logiquement être proposée dans Debian 9 Stretch), ainsi que dans un certain nombre d’autres distributions GNU/Linux.

Par ailleurs, comment ne pas signaler que, peu après la parution de GNOME 3.20, Gedit a finalement été doté d’une nouvelle version pour systèmes Microsoft Windows ? La 3.20.1 pour Windows 64 bits succède donc à la 2.30 pour Windows 32 bits !

Vitalité du projet

Notons tout d’abord le satisfecit donné par un des développeurs de Fichiers concernant la petite équipe de développement qui s’est formée depuis un an et demi autour de ce composant majeur de notre environnement de bureau favori et qui revient de loin, semble‐t‐il, pour le coup.

Voyons ensuite les statistiques de développement de la précédente version (3.20) de GTK+ présentées par Emmanuele Bassi (qui avait déjà fait le point à l’occasion de la version 3.18 en deux billets). Au passage, on se rend mieux compte du travail qu’a représenté la refonte du « thémage » avec le CSS (le nombre de lignes de code ajoutées et supprimées atteint respectivement 158 427 et 117 823 dans la version 3.20 de GTK+, contre 78 676 et 54 508 dans la version précédente).

Ce billet liste les projets retenus pour le Google Summer of Code 2016.

À l’occasion du GNOME Asia Summit 2016, Tobias Mueller [blogue] est revenu sur les cinq ans de GNOME 3.

Autour de GNOME

Pitivi

Les versions 0.96 et 0.97 de Pitivi, le logiciel de montage vidéo non linéaire libre, puissant et intuitif, qui partage les technologies du bureau GNOME (la boîte à outils graphiques GTK+, le moteur multimédia GStreamer) et respecte ses bonnes pratiques pour l’IHM (énoncées ici), sont sorties durant ce cycle de développement (respectivement les 30 juin et 8 août 2016). Si votre distribution ne vous propose pas encore cette version, vous pouvez récupérer un paquet Flatpak de cette dernière version sur le site officiel du projet qui propose également un canal nightly.

LibreOffice et Firefox

La version 5.2 de LibreOffice (sortie le 3 août 2016), la suite bureautique phare du monde libre, améliore son intégration graphique dans un environnement GTK+ (billets de blogue un et deux).

En passant à la version 46 (sortie le 26 avril 2016, voir notre dépêche), Firefox, notre navigateur préféré, embrasse GTK+ 3 (sous réserve des choix faits à la compilation par votre distribution).

Shotwell et Geary

Bonne nouvelle : deux logiciels orphelins depuis l’arrêt de la fondation Yorba en novembre 2015 ont successivement retrouvé un foyer.

Il s’agit tout d’abord du logiciel de gestion de photos personnelles Shotwell, pour lequel Jens Georg a proposé de reprendre les rênes du projet à compter de la version 0.22.1 parue le 15 avril 2016 ! Du coup, une version 0.23 est sortie quelques jours après.

Il s’agit ensuite du logiciel de messagerie Geary, pour lequel Michael Gratton s’est également manifesté et a publié la version 0.11.0 le 15 mai 2016, ainsi que deux versions mineures 0.11.1 et 0.11.2.

Systemd Manager

Systemd Manager est un tout jeune logiciel (son développement a débuté en novembre 2015) repéré par Okki qui en a fait un billet de présentation. Ce logiciel, qui permet, entre autres, de démarrer et arrêter graphiquement les différents services gérés par systemd, est développé principalement par Michael Murphy, alias mmstick, qui semble fan de Rust (il contribue également à Redox OS) et GTK+ 3 pour ses différents projets logiciels, dont celui‐ci :



GUADEC 2016 & 2017

Le GUADEC (GNOME Users And Developers European Conference), Conférence européenne annuelle des utilisateurs et développeurs GNOME, pour les francophones.

L’édition 2016 a eu lieu à Karlsruhe, en Allemagne, du 12 au 17 août 2016 :

L’édition 2017, devrait se dérouler en été à Manchester, en Angleterre.

Aller plus loin