Deux nouveaux PC hybrides vendus directement sous GNOME

Fin 2014, l’entreprise américaine Purism lançait une campagne de financement participatif dans le but de pouvoir produire un ordinateur portable entièrement libre. Sans aller jusqu’à de l’open hardware, toute la partie logiciel se devait d’être libre. Ceci incluait aussi bien le logiciel d’amorçage (coreboot), le système d’exploitation, les pilotes de périphériques et bien évidemment les applications.

Des 250 000 dollars initialement demandés, ils réussirent à récolter près de 610 000 dollars, ce qui leur permit de sortir non pas un mais deux ordinateurs portables, Librem 13 et Librem 15, équipés de processeurs i5 et i7 de cinquième génération (Haswell), de 16 ou 32 GB de RAM, d’un SSD… classique, mais néanmoins onéreux, puisque commercialisés 1499 et 1899 dollars.

L’histoire aurait donc pu s’arrêter là, mais voilà que Purism vient de lancer la prévente sur Indiegogo de deux nouveaux ordinateurs portables hybrides, dont l’écran sera détachable pour faire office de tablette. Et c’est là que ça devient intéressant, puisque la nouvelle version de PureOS, le système d’exploitation maison autrefois basé sur Trisquel (un dérivé entièrement libre d’Ubuntu) et Cinnamon (un environnement de bureau dérivé de GNOME), fait un retour aux sources en se basant désormais sur Debian et GNOME. Les deux tablettes utiliseront donc bien GNOME Shell par défaut.

La Librem 10 en mode tablette

Depuis le temps qu’on entend les trolls se plaindre que GNOME Shell est entièrement pensé pour le tactile alors qu’aucune tablette ne semblait l’exploiter, entre ces deux nouveaux produits commercialisés directement sous GNOME ou le succès grandissant des PC hybrides (Microsoft Surface, Lenovo Yoga, HP Spectre…), c’est une bonne chose de constater que parmi tous les environnements de bureau libres disponibles, il en existe au moins un parfaitement adapté à ce type de configuration.

Pour en revenir à Purism, nous avons donc le modèle Librem 10, équipé d’un processeur Atom x5-Z8300, de 4 GB de RAM, de 64 GB d’espace disque et d’un écran 10.1″. Le tout vendu 599 dollars.

Vient ensuite la Librem 11, qui aura droit à deux déclinaisons. Une première, équipée d’un processeur Intel Core M-5Y10c, de 8 GB de RAM, d’un SSD de 256 GB et d’un écran 11.6″. Ainsi qu’une seconde, dont la RAM et le SSD passent respectivement à 16 GB et 512 GB. En ce qui concerne le prix, si vous précommandez dès maintenant, ça se fera à 999 ou 1567 dollars. Mais une fois la prévente terminée, ça grimpera ensuite à 1299 ou 1867 dollars.

Précommandes oblige, les livraisons devraient débuter en octobre 2016.

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.

Afficher des dates plus précises dans Fichiers

Par défaut, dans la vue en liste, Fichiers n’affiche plus qu’une date de modification simplifiée (aujourd’hui, hier, jeudi…). Ce comportement peut être problématique quand l’heure est importante pour vous, et qu’elle peut vous aider à retrouver un document parmi un ensemble de fichiers créés le même jour, ou de pouvoir reconstituer la chronologie d’une suite de modifications.

Fichiers 3.20 affichant des dates de modification simplifiées

Pour ce faire, il vous suffit de vous rendre dans les préférences, de sélectionner l’onglet Colonnes des listes, puis de décocher Dernière modification, que vous remplacerez par Date de modification.

Fichiers 3.20 affichant des dates de modification plus précises

Sortie de la première version du thème d’icônes Arc

Le thème GTK+ Arc et le thème d’icônes Arc

horst3180, le créateur du plus populaire des thèmes GTK+, Arc, vient de sortir la toute première version d’un thème d’icônes associé, Arc Icon Theme.

Le thème n’en est encore qu’à ses débuts, et se contente pour le moment de couvrir les icônes de dossiers et les type MIME. Quand le thème ne propose pas ses propres icônes, il utilise par ordre de préférence celles des thèmes Moka et Adwaita.

Si vous préférez faire appel aux icônes Faenza ou modifier l’ordre de préférence, il vous faut éditer le fichier Arc/index.theme puis modifier la ligne Inherits de la section [Icon Theme].