GNOME 3.22 Karlsruhe : A Land Far, Far Away

98
28
sept.
2016
Gnome

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

logo de GNOME

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 !

logo Wayland

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).
Configuration des boutons de tablette graphique

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 ) 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

Nouvelle vue des paramètres (crédit : feaneron)

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…
Rappel évènement

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.

Renommage par patron de fichiers musicaux

Renommage par « cherche et remplace »

À 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.

Compression d'archives et barre de progression

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.

Menu de droite

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 ;
  • nouvelle icône.

Flatpak

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

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 ;
  • 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 ;
  • 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) ;
  • 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 :

The new versioning scheme

GStreamer

La compilation de GStreamer bientôt confiée à Meson plutôt que les Autotools

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 :
Capture d’écran de systemd-manager

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.

  • # Merci

    Posté par (page perso) . Évalué à 10.

    Merci à ceux qui ont bouclé cette dépêche à un moment où je n'ai pu le faire moi-même :)

  • # GTK+4

    Posté par (page perso) . Évalué à 6.

    Pour ceux que cela intéresse, il y a déjà un fil sur la décision de sortir « déjà » GTK+4 sous lé depêche de sortie de Firefox 49 ;)

    • [^] # Re: GTK+4

      Posté par (page perso) . Évalué à -1.

      Au risque de lancer un troll énorme, je pense que les gens qui critiquent GTK3 n'ont pas compris ce qu'il offre comme nouvelle façon de concevoir une interface graphique.

      Pour le coup des CSS, le(s) mec(s)/fille(s) qui avaient fait le travail d'origine avaient fait des mauvais choix, ben on les corrige.

      Et franchement, ça se résumait à changer:
      GtkTreeView par treeview (entre autre)

      Whaou, au moins 3 semaines de dev pour adapter son logiciel à la nouvelle version de GTK…

      • [^] # Re: GTK+4

        Posté par . Évalué à -2.

        Quand KWin inclut un script pour éviter les CSS, on se dit que c'est peut-être pas si facile.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: GTK+4

          Posté par (page perso) . Évalué à 5.

          Tu confonds CSS(tu sais le truc du web) et Client Side Decoration…

          • [^] # Re: GTK+4

            Posté par . Évalué à 0.

            Ah, oui. J'ai lu CSD.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: GTK+4

        Posté par . Évalué à 5.

        Je parlais du fait de passer toute une base de code de Gtk2 à Gtk3. Contrairement à ce que tu prétends, ça ne se résume pas à changer un seul appel de méthode.
        De plus les liens inclus dans la dépêche démontrent bien la non stabilité de GTK3 lui-même et les conséquences que cela peut avoir au niveau du développement et du packaging dans les distributions. Ce n'est pas trivial et c'est même décourageant pour les applications utilisatrices.

    • [^] # Re: GTK+4

      Posté par . Évalué à 6.

      Je serai plus nuancé sur le « déjà ».

      Je comprends mieux le besoin d'itérer rapidement pour l'équipe GTK+ et je trouve que la solution qu'ils proposent et un compromis intéressant. Ça embête un peu toutes les parties prenantes: GTK+ et application utilisatrices, ce qui en fait donc un bon compromis.

      Ceci dit je reste persuadé que du point de vue applications utilisatrices, 2 ans c'est trop court.
      Si les changements sont très nombreux, les application utilisatrices genre LibreOffice, Firefox ou Eclipse ont besoin de temps pour pouvoir faire les changements nécessaires, et laisser le toolkit graphique se stabiliser. De par leur taille et leur aspet framework, elles touchent beaucoup de corner cases qui ralentissent l'effort de migration.

      • [^] # Re: GTK+4

        Posté par (page perso) . Évalué à 7.

        Ceci dit je reste persuadé que du point de vue applications utilisatrices, 2 ans c'est trop court.

        La maintenance est de 3 ans minimum, cf. la dépêche (basée sur le post officiel). Ensuite on peut faire plus long, mais il y a toujours des limites en particulier financières, car même s'il y a pas mal de contributeurs payés, ce n'est pas encore au niveau du noyau par exemple; et surtout pour qu'il puisse y avoir une version "long terme", il faut en général qu'il y ait au moins une entreprise intéressée et qui paye donc un mainteneur pour cela. Donc quand GNOME deviendra plus répandu (je trouve personnellement que c'est sur la bonne pente. De plus en plus d'entreprises basent leurs produits sur GNOME, comme RedHat ou Endless; des grosses entreprises travaillent notamment avec GNOME, comme Pixar), ce n'est pas impossible qu'il y ait des gens intéressés par des versions long terme de GTK+.
        Mais pour l'instant, 3 ans ("minimum" en plus, donc ça peut être plus au cas par cas), c'est quand même pas mal.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: GTK+4

          Posté par . Évalué à 3.

          Merci de ton commentaire. 3 ans minimum c'est mieux et c'est encourageant.

          Puisque tu as l'air de suivre plus en détail les changements de GTK, est-ce qu'il prévoient encore de gros changements d'APIs et/ou de comportement pour la suite (GTK4, 5, 6, …) ou bien est-ce que les APIs de base vont tendre vers une stabilisation générale?

          Bien sûr je ne prétend pas à une stabilité totale puisqu'on n'est pas à l'abri d'un changement de paradigme comme dans GTK3 (CSS, tablettes, etc.)

          • [^] # Re: GTK+4

            Posté par (page perso) . Évalué à 4.

            Puisque tu as l'air de suivre plus en détail les changements de GTK

            Je ne suis pas particulièrement GTK+. J'ai découvert pas mal de choses en lisant des posts parce que j'ai participé à la dépêche. Et aussi avec le fait d'avoir été au GUADEC.

            est-ce qu'il prévoient encore de gros changements d'APIs et/ou de comportement pour la suite (GTK4, 5, 6, …) ou bien est-ce que les APIs de base vont tendre vers une stabilisation générale?

            C'est pas qu'ils prévoient des changements d'APIs ou de comportements. Dit comme ça, on dirait presque que ça veut dire "yeah on va tout casser juste pour embêter les gens". ;-P
            C'est simplement que les technologies évoluent, ainsi que les développeurs. Un exemple classique, c'est de faire une erreur conceptuelle. Cela ne rend pas une API forcément inutilisable pour autant, mais ça peut la rendre limitée, chiante à utiliser, voire aberrante (dans certains cas, mais pas d'autres peut-être, ce qui peut expliquer l'erreur car le dév n'a pas vu le problème immédiatement). Tout développeur est tombé sur ce type d'API un jour dans une librairie ou une autre. Ben un changement de version majeure est l'occasion pour casser ce type d'API et les rendre plus logique et utilisable.
            Et puis tout simplement, faut bien suivre les technologies. Dans ce genre de librairies, les APIs sont en générale suffisamment abstraites pour qu'un changement de technologie sous-jacente (on va penser au passage de X à Wayland par exemple, mais y a aussi plein d'autres technologies qui sont des briques essentielles de GTK+) ne change pas ces dernières. Mais encore une fois, le monde n'est pas parfait, et il est possible que des points de l'interface doivent être légèrement adaptées.

            En gros, vouloir une stabilité totale, ce serait un peu une lubie avec un librairie aussi étendue (c'est à dire qui touche tant de sujet, donc tant de technologies) que GTK+. Du moins si on veut vivre avec son temps et faire évoluer la librairie.
            Ensuite je ne doute pas une seconde que les dévs ne vont pas s'amuser à tout changer tout le temps. Ils ne le feront que lorsque cela s'avèrera nécessaire.

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: GTK+4

          Posté par (page perso) . Évalué à 3.

          Mais pour l'instant, 3 ans ("minimum" en plus, donc ça peut être plus au cas par cas), c'est quand même pas mal.

          3 ans c'est ridicule par rapport à la durée de vie des gros logiciels: Gimp a 20 ans, (Netscape|Firefox) aussi, (Star|Libre)office 30 ans…

          Même un projet perso dure souvent 5 à 10 ans.

          http://devnewton.bci.im

          • [^] # Re: GTK+4

            Posté par (page perso) . Évalué à 8.

            On parle de maintenance par version, pas par logiciel (quelle idée étrange. Je crois pas qu'ils prévoient d'arrêter de développer GTK+ dans 3 ans! :P). Tu peux pas comparer l'âge d'un logiciel et la durée de maintenance d'une version. Par exemple pour GIMP, avec le nombre extraordinaire de développeurs qu'on a (ironie), je peux t'assurer que notre maintenance d'une version s'arrête dès qu'on sort la version suivante. Par exemple GIMP 2.6 a cessé d'être maintenue à la sortie de 2.8 (je pense, j'y étais pas, mais en tous cas on touche pas à la 2.6 depuis des années. Moi j'y ai jamais touché). Et 2.8 cessera d'être maintenu probablement à la sortie de 2.10, ou peu après (mais sûrement pas 3 ans).
            La seule raison pour laquelle cette durée reste longue dans le cas de GIMP, c'est qu'on met trop de temps à sortir les nouvelles versions (pour la même raison de peu de développeurs). :-/

            C'est un peu comme si on te demandait de faire des corrections de bug sur des versions anciennes de Newton Adventure. Tu accepteras (peut-être?) de backporter certaines corrections (si tu dois aussi les faire sur la dernière version notamment, mais des fois le bug n'apparaît que sur les vieilles versions donc c'est potentiellement des heures de travail qui n'ont même pas d'incidence sur la version en cours), mais jusqu'à un certain point, j'imagine. Ton temps est quand même limité. Enfin je sais pas exactement quel est ton modèle de développement et peut-être acceptes-tu de corriger des bugs sur des versions de plus de 3 ans (bug qui potentiellement ne touche pas ta dernière version)? :-)

            Ceux qui peuvent se permettre plus sont les logiciels avec plus de développeurs, notamment payés, comme GTK+ (et 3 ans, c'est vraiment pas mal). Même le noyau linux, leurs versions long-terme de plus longue durée sont seulement de 6 ans en ce moment (la version 3.2 jusqu'à 2018 et 3.16 jusqu'à 2020). Il est d'ailleurs intéressant de voir qu'ils ont des versions prévues avec "seulement" 2 ans de maintenance et qu'ils qualifient aussi de long-terme (la 4.1 dans le lien donné).

            Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: GTK+4

              Posté par (page perso) . Évalué à 5.

              Le problème c'est qu'entre deux versions de GTK, on peut avoir des changements non rétrocompatible, voire des refontes complètes. Voir son logiciel cassé tous les 3 ans (ou même 5 ou 10) à cause d'une API instable, ce n'est pas acceptable.

              http://devnewton.bci.im

              • [^] # Re: GTK+4

                Posté par (page perso) . Évalué à 5.

                Pourquoi veux tu que ça casse ? Si ton application utilise GTK+ 3, quand les versions 4, 5 ou 6 sortiront, ton application continuera d'utiliser la version 3. Par conséquent, ils peuvent bien faire ce qu'ils veulent dans les versions suivantes, ça ne touchera pas à la stabilité de ton application. La seule chose, c'est qu'une fois la période de maintenance écoulée, ils ne corrigeront plus d'obscurs bugs qui pourraient être trouvés entre temps, ou ne corrigeront peut être pas toutes les failles de sécurité (reste à voir la politique des distributions avec support long, genre RHEL).

                • [^] # Re: GTK+4

                  Posté par (page perso) . Évalué à 5.

                  Tout à fait. Pourquoi ça casserait? Si tu souhaites rester sur une vieille version de GTK+, tu seras juste sur une vieille version qui n'aura plus de mises-à-jour, donc pas de correction de bugs en particulier, mais c'est tout. Ça "cassera" pas, et ton application tournera toujours pareil.

                  Bon par contre, une distribution pourrait retirer les paquets pour une vieille version de GTK+ qui n'est plus maintenue, et si ton logiciel se base dessus, c'est problématique. Mais là encore, ce sera la même chose pour n'importe quelle autre bibliothèque en dépendance si tu souhaites absolument rester sur une vieille version.
                  Ta solution dans ce cas pourra être de faire un paquet indépendant qui incorpore la version adéquate, par exemple avec Flatpak.

                  Franchement je comprends pas ces peurs et attaques en règle de GTK+, alors que 3 ans de support par défaut (c'est à dire qu'il y aura toujours possibilité d'avoir plus pour ceux qui payent), c'est vraiment une durée très très appréciable que peu de logiciels fournissent (libres ou propriétaires d'ailleurs). Comme je l'ai dit plus bas, Qt ont la même durée pour leur version LTS par exemple.
                  Quand GTK+ avait un modèle de développement instable, je pouvais comprendre les critiques. Mais là ils essaient de venir sur un modèle plus stable et surtout avec une durée de maintenance très correcte. Il y a très peu de logiciels libres qui ont une maintenance aussi longue par défaut (en gros, que les autres gros). Donc franchement, je comprends plus les critiques.
                  Je pense que c'est au contraire à saluer.

                  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                  • [^] # Re: GTK+4

                    Posté par (page perso) . Évalué à 2.

                    Et quand GIMP 2.10 sortira, on aura déjà GTK+5 c'est dire tout ce à quoi il pourra avoir accès ! ;)

                  • [^] # Re: GTK+4

                    Posté par (page perso) . Évalué à 3.

                    Plus sérieusement, je me demande comment va fonctionner le duo GNOME-GTK+ à l'avenir : est-ce que GNOME 3.24 sera basé sur GTK+ 3.22.x, c-a-d restera sur la branche stable de GTK+ ?

                    • [^] # Re: GTK+4

                      Posté par (page perso) . Évalué à 3.

                      Non, ils ont d'ores et déjà annoncés qu'ils utiliseraient les dernières versions proposant les dernières nouveautés.

                      • [^] # Re: GTK+4

                        Posté par (page perso) . Évalué à 4.

                        Du coup on aura GNOME 3.24 sur GTK 3.90 et parallèlement des applis continueront d'utiliser GTK 3.22.x ?

                        • [^] # Re: GTK+4

                          Posté par (page perso) . Évalué à 4. Dernière modification le 02/10/16 à 12:32.

                          Oui. Il pourra y avoir plusieurs versions de GTK+ installées sur un système (comme actuellement GTK+2 et GTK+3). Le pkg-config des versions 3.9x sera appelé gtk+-4.0,permettant une installation en parallèle et montrant bien que les versions x.9y sont en fait des versions de développement qui visent l'API de la version x+1.

                          L'idée est que les applis core GNOME sont suffisamment proche de GTK+ (donc suivent le développement de près) pour les avoir suivre la version de dév (ce qui sera en gros similaire à maintenant). Alors que les applis tierces auront le choix: elles auront le droit de suivre aussi la version de dév, qui aura les nouveautés et autres trucs hype, pour le prix d'un coup de maintenance un peu plus poussée; mais elles pourront aussi se rabattre sur la version stable qui sera assurée de ne pas casser les apps.

                          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: GTK+4

              Posté par . Évalué à 6.

              Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)

              Pour gnome, oui. Pour gtk, c’est vachement plus discutable. Surtout comparé à Qt.

              Sincèrement, j’aime beaucoup le bureau gnome, mais par contre, pour développer, je recommande largement plus Qt. J’ai plein de choses à lui reprocher, mais la stabilité des APIs, ça fait toute la différence.

              Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

              • [^] # Re: GTK+4

                Posté par (page perso) . Évalué à 7.

                Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)

                Je voulais dire GTK+, pas GNOME, bien sûr (tout le reste de mon post parlait de GTK+). C'est une erreur par amalgame!

                Pour gnome, oui. Pour gtk, c’est vachement plus discutable. Surtout comparé à Qt.

                Cette remarque m'a étonné. Je me suis demandé quel était le temps de maintenance des versions de Qt. Hop, petit coup de moteur de recherche, et je trouve donc leur version "long term support" (Qt 5.6), qui est de… 3 ans garantis! Exactement comme GTK+.

                Ils précisent qu'il y aura possibilité d'acheter du support additionnel… similairement à GTK+ encore une fois (dans le cas de GTK+, ils disent de les contacter pour discuter d'une politique de backport. Je pense que cela signifie que l'approche est différente en ce sens qu'ils sont probablement pas contre un support allongé pour une entreprise qui souhaite payer un employé pour s'en occuper, ce qui est similaire au modèle du noyau par exemple; alors que le modèle Qt est annoncé comme plus entrepreneurial, il semblerait).

                En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
                Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)

                Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                • [^] # Re: GTK+4

                  Posté par (page perso) . Évalué à 5.

                  En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.

                  Sauf qu'il n'y a pas que Qt et Gtk. Le vrai concurrent c'est html/js/css dont la durée de support est "infini".

                  http://devnewton.bci.im

                  • [^] # Re: GTK+4

                    Posté par (page perso) . Évalué à 4.

                    Pas convaincu. De nos jours, les développeurs vont utiliser de gros frameworks, genre Electron, qui va lui-même se baser sur Node.js. Tu retrouves donc la notion de version et de compatibilité.

                  • [^] # Re: GTK+4

                    Posté par (page perso) . Évalué à 8.

                    Oui, toujours ce couple html/js qui va remplacer les applications natives… 10 ans qu'on en parle, 10 ans que c'est un échec…

                    • [^] # Re: GTK+4

                      Posté par (page perso) . Évalué à 2.

                      10 ans, c'est court pour juger d'un échec :-) On y arrive tout doucement. Les seules applis natives que j'utilise sont:

                      • de très anciennes qui n'ont pas migrées sur le web (gimp, libreoffice, eclipse, vlc).
                      • celles qui demandent des performances maximales (les jeux, virtualbox).
                      • les navigateurs webs forcément :-)

                      Pour certaines de ces applications, la bascule est en cours: les jeux jouables dans un navigateur ne sont plus rare, eclipse se cloudifie, les suites bureautiques en ligne sont là…

                      http://devnewton.bci.im

                      • [^] # Re: GTK+4

                        Posté par (page perso) . Évalué à 4. Dernière modification le 02/10/16 à 19:58.

                        Et sur ton téléphone ? Perso, je préfère toujours une appli native à une webapp, pour tout ce qui ne relève pas de la pure consultation d'information textuelle (dans ce contexte, évidemment, un site web est préférable - et encore, s'agissant de la météo…). Bien qu'au fond, pour l'utilisateur final, ça ne fait guère de différence : une appli est une appli. Et du moment qu'elle fonctionne correctement, qu'importe la manière dont elle a été codée.

                        • [^] # Re: GTK+4

                          Posté par (page perso) . Évalué à 4.

                          Oui, mais c'est bien là le problème, aucune application html/js n'est aussi performante qu'une application native, et c'est bien sur un téléphone que l'on s'en rend compte…

                          • [^] # Re: GTK+4

                            Posté par . Évalué à 2.

                            Peux etre mais bon le probleme c'est que c'est pas GTK sur le telephone. Il me semble meme que le ubuntu phone c'est du QML et donc Qt mais je dois avoir tord je n'ai pas suivi tout le truc.

                          • [^] # Re: GTK+4

                            Posté par (page perso) . Évalué à 5.

                            A part les jeux, 99% (d'après le Dave Institute Of Pyfometry) des applis sont des webviews non?

                            http://devnewton.bci.im

                          • [^] # Re: GTK+4

                            Posté par . Évalué à 2. Dernière modification le 06/10/16 à 01:26.

                            Si l'application ne fait rien d'exceptionnel (comme la plupart d'entre elles) et que le téléphone est relativement récent (on va dire moins de 2 ans) je doute qu'on puisse faire la différence entre app native et web app, que ce soit au niveau de la performance ou de l'intégration graphique avec Android/iOS.

                            Personnellement je n'ai eu des problèmes de performances avec Cordova et Ionic que dans des cas très spécifiques (exemples : centaines de marqueurs affichés sur une map, liste infinie contenant images et vidéos). Dans la plupart des cas que j'ai vu c'est l'utilisation d'Angular v1 qui plombe les performances (quelle idée le two-way data-binding par défaut…) au contraire d'Angular2 ou React.

                    • [^] # Re: GTK+4

                      Posté par . Évalué à 2.

                      Quand on voit la quantité d'applications desktop comme mobile qui sont développées HTML, CSS et JS ça me semble au contraire un succès.
                      Il suffit de voir la popularité des projets Electron, NW.JS, Cordova et Ionic pour s'en convaincre.

                      • [^] # Re: GTK+4

                        Posté par (page perso) . Évalué à 3.

                        Il suffit de voir la popularité des projets Electron, NW.JS, Cordova et Ionic pour s'en
                        convaincre.

                        Sur IOS et Android?

                        • [^] # Re: GTK+4

                          Posté par . Évalué à 0.

                          Electron et NW.JS fonctionnement pour toutes les plateformes desktop, et Cordova pour toutes les plateformes mobiles.

                  • [^] # Re: GTK+4

                    Posté par . Évalué à 7.

                    HTML5 est très pauvre… C'est pour ça que les gens utilisent bootstrap. Et ce dernier n'a pas de scrupule à casser la compatibilité.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: GTK+4

                      Posté par (page perso) . Évalué à 0.

                      Tu confonds cadriciel et API.

                      http://devnewton.bci.im

                      • [^] # Re: GTK+4

                        Posté par . Évalué à 4.

                        Non, le fait que les primitives bas niveau soient stables ne changent rien. Sinon je peux te rétorquer que xcb est très stable.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: GTK+4

                          Posté par (page perso) . Évalué à 1.

                          Tout dépends ce que tu entends par primitives…

                          Bref dans le baril html, j'ai une compatibilité éternelle et de nouvelles fritures disruptives tous les ans.

                          Alors qu'avec le baril de GTK, qu'y a-t-il à part des cassages réguliers et 3 widgets qui se battent en duel à force d'épurations?

                          http://devnewton.bci.im

                          • [^] # Re: GTK+4

                            Posté par . Évalué à 2.

                            Il y a largement plus de widgets sur n'importe quel toolkit (y compris tk) que dans HTML5.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: GTK+4

                              Posté par (page perso) . Évalué à 1.

                              Ca ne réponds pas à la question: pourquoi choisir GTK plutôt qu'autre chose en 2016?

                              http://devnewton.bci.im

                              • [^] # Re: GTK+4

                                Posté par . Évalué à 9.

                                La force de gtk c'est d'avoir des bindings dans un paquet de langages. Là où Qt en a sur un nombre plus limité (certains diront quantité vs qualité).

                                Face à la majorité des autres bibliothèques, gtk a l'avantage d'être portable (même si ça demande du travail pour que ce soit propre…).

                                Face à du HTML5, ben gtk est vachement plus sympa que HTML5 vanilla (gestion du layout plus simple, plus de composants graphiques). Face à HTML5 + la bibliothèque de composant de ton choix, gtk permet de ne pas avoir à faire un truc frontend/backend entre ton appli et ton interface.

                                Pourquoi vouloir cracher dessus ? C'est un projet qui suit son bonhomme de chemin, il est très utilisé, ils font ce qu'ils peuvent pour s'améliorer (c'est peut être jamais assez mais ils tentent de prendre en compte ce que les gens disent),… Pourquoi chercher à piétiner comme ça ce travail ?

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: GTK+4

                                  Posté par (page perso) . Évalué à 1.

                                  Face à du HTML5, ben gtk est vachement plus sympa que HTML5 vanilla (gestion du layout plus simple, plus de composants graphiques).

                                  C'est très subjectif.

                                  Face à HTML5 + la bibliothèque de composant de ton choix, gtk permet de ne pas avoir à faire un truc frontend/backend entre ton appli et ton interface.

                                  Lapin compris.

                                  Pourquoi chercher à piétiner comme ça ce travail ?

                                  Étudier une lib/API du point de vue du dissaïdeur pressé, ce n'est pas chercher à piétiner le travail…

                                  http://devnewton.bci.im

                                  • [^] # Re: GTK+4

                                    Posté par . Évalué à 8.

                                    Face à du HTML5, ben gtk est vachement plus sympa que HTML5 vanilla (gestion du layout plus simple, plus de composants graphiques).

                                    C'est très subjectif.

                                    Le fait que la gestion du layout soit plus simple est un fait. CSS3 arrive enfin avec flexbox, mais c'est encore simpliste face à ce que propose n'importe quelle bibliothèque (ou bibliothèque de composants HTML). Pour les composants c'est pareil, essaie vraiment un jour de t'interdire une bibliothèque de composants, tu comprendra vite pourquoi ça a du succès.

                                    Face à HTML5 + la bibliothèque de composant de ton choix, gtk permet de ne pas avoir à faire un truc frontend/backend entre ton appli et ton interface.

                                    Lapin compris.

                                    Tu as le choix du langage sans devoir interfacer ton code dans le langage que tu souhaite avec une vue HTML (un lien entre ton appli et un nodejs/Electron ou faire du binding avec un runtime js dans ton application).

                                    Étudier une lib/API du point de vue du dissaïdeur pressé, ce n'est pas chercher à piétiner le travail…

                                    Effectivement, mais tu as dépassé le cadre de la critique quand tu dis :

                                    Alors qu'avec le baril de GTK, qu'y a-t-il à part des cassages réguliers et 3 widgets qui se battent en duel à force d'épurations?

                                    On est à minima dans de la condescendance qui à mon avis est mal placée.

                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: GTK+4

                                  Posté par . Évalué à 4.

                                  La force de gtk c'est d'avoir des bindings dans un paquet de langages

                                  Je ne vois pas trop en quoi c'est une force. Quand on écrit une appli, en général, on se fixe sur un langage donné, donc le fait que les bindings soient disponibles pour un paquet de langages n'entre pas en ligne de compte.

                                  Par ailleurs, comme l'immense majorité des applis sont codées en C++, Java, C# ou Python, le reste des bindings (du genre Haskell-gtk ou PHP-gtk) n'a guère qu'un intérêt décoratif.

                                  • [^] # Re: GTK+4

                                    Posté par . Évalué à 5.

                                    C'est bizarre, tu fais la réflexion à l'envers. Il te laisse la liberté d'utiliser le langage de ton choix parmi un grand nombre (pour une bibliothèque graphique) et cela sans que tu ai à gérer toi-même un binding vers du C. L'intérêt est donc d'être moins contraint, même si une fois le choix effectué (ou si tu as déjà un existant), tu n'a pas besoin d'avoir les autres.

                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                    • [^] # Re: GTK+4

                                      Posté par . Évalué à 2.

                                      Liberté purement formelle puisque, si j'écrivais une GUI, je n'utiliserais pas un langage « obscur » mais à coup sûr un langage faisant partie des langages supportés par Qt.

                                      Si je choisis un langage, la seule contrainte n'est pas la seule disponibilité du toolkit graphique. C'est aussi ma familiarité avec ce langage, son adéquation à la tâche, et la facilité à trouver d'autres contributeurs ou développeurs (ce qui implique un langage plutôt populaire).

                                      C'est un peu comme dire qu'il vaut mieux utiliser NetBSD qu'Ubuntu parce que NetBSD est porté sur plus d'architectures. Pour la plupart des gens, cela n'a aucune importance.

                                      • [^] # Re: GTK+4

                                        Posté par . Évalué à 9.

                                        Liberté purement formelle puisque, si j'écrivais une GUI, je n'utiliserais pas un langage « obscur » mais à coup sûr un langage faisant partie des langages supportés par Qt.

                                        Si je choisis un langage, la seule contrainte n'est pas la seule disponibilité du toolkit graphique. C'est aussi ma familiarité avec ce langage, son adéquation à la tâche, et la facilité à trouver d'autres contributeurs ou développeurs (ce qui implique un langage plutôt populaire).

                                        Et tu me vois ravis de l'apprendre…

                                        C'est un peu comme dire qu'il vaut mieux utiliser NetBSD qu'Ubuntu parce que NetBSD est porté sur plus d'architectures.

                                        Sauf que ce n'est pas ce que j'ai dis. Je n'ai pas dis que gtk était mieux que quelque chose d'autre. J'ai décris quelques points qui le démarque. Que ce point soit anecdotique, c'est pas forcément faux (disons qu'il y a un historique derrière Qt n'a pas toujours eu autant de binding et gtk fait tout ces bindings avec bien moins de ressources humaines).

                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                        • [^] # Re: GTK+4

                                          Posté par (page perso) . Évalué à 1.

                                          Tu peux aussi prendre en compte que les bindings Qt sont mal documentés, mal supportés, voir même fragmentés (PyQt vs PySide)

                                      • [^] # Re: GTK+4

                                        Posté par (page perso) . Évalué à -1.

                                        J'ajoute que les langages populaires ont leurs propres toolkits au moins aussi bien, voir meilleur que Gtk ou Qt (ceux qui viennent avec le JDK ou .NET par exemple).

                                        http://devnewton.bci.im

                                        • [^] # Re: GTK+4

                                          Posté par . Évalué à 7. Dernière modification le 04/10/16 à 21:07.

                                          Tu rigole ? Swing est pas terrible, c'est presque plus maintenu et il se base sur gtk (tu sais le truc que tu sais pas pourquoi ça existe).

                                          Pour .Net, WPF n'est pas portable. Je ne suis même pas sûr que ce soit le standard en cours. Si je ne m'abuse, MS pouse les universal app en js. .Net Core a une bibliothèque graphique ? Mono utilise Gtk#…

                                          Go et rust n'ont rien. Swift doit avoir cocoa évidemment, mais pas dans la base open source et portable.

                                          Tu pense à quels langages ?

                                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                          • [^] # Re: GTK+4

                                            Posté par . Évalué à 4.

                                            Tu rigole ? Swing est pas terrible, c'est presque plus maintenu et il se base sur gtk (tu sais le truc que tu sais pas pourquoi ça existe).

                                            Non, swing c'est du pur java (contrairement à son ancêtre AWT, sur lequel il est malheureusement basé).
                                            Dans la version X11/Linux de java, il y a un style qui utilise GTK, mais ce n'est pas celui par défaut et il ne fonctionne pas très bien (mais la dernière fois que je l'ai essayé je pense que c'était encore java 6, ou peut-être 7).

                                            • [^] # Re: GTK+4

                                              Posté par . Évalué à 3.

                                              Non, swing c'est du pur java (contrairement à son ancêtre AWT, sur lequel il est malheureusement basé).

                                              Justement il me semble que swing n'a pas tout refais et donc continue d'utiliser AWT. Il utilise des parties d'AWT qui n'utilisent pas gtk ? Dis autrement, il est possible d'utiliser swing sans gtk du tout ?

                                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                          • [^] # Re: GTK+4

                                            Posté par (page perso) . Évalué à 1.

                                            Swing est pas terrible, c'est presque plus maintenu et il se base sur gtk (tu sais le truc que tu sais pas pourquoi ça existe).

                                            Tu confonds avec AWT. Swing est beaucoup plus évolué (le designer et le système de layout sont les meilleurs que je connaisse).

                                            Niveau maintenance, c'est top:

                                            • le jdk inclue toujours AWT, Swing et maintenant JavaFX.
                                            • les trois s'intègrent les uns avec les autres.
                                            • les nouvelles API sont conseillées, mais les anciennes sont maintenues très très très longtemps (je n'ai jamais rien vu disparaître du JDK).

                                            Le défaut c'est que ça se bloate, mais la RAM est moins chère que les jours/hommes…

                                            http://devnewton.bci.im

                              • [^] # Re: GTK+4

                                Posté par (page perso) . Évalué à 4.

                                Parce que je déteste JavaScript et HTML?

                                • [^] # Re: GTK+4

                                  Posté par (page perso) . Évalué à 5.

                                  C'est le moment d'acheter une veste en cuir, de te faire une crête et d'aller écrire await no_future() sur le mur du w3c!

                                  http://devnewton.bci.im

                                  • [^] # Re: GTK+4

                                    Posté par (page perso) . Évalué à 5.

                                    Au sens j'aime pas coder avec ça, pas au sens j'ai envie de bruler le W3C…

                • [^] # Re: GTK+4

                  Posté par . Évalué à 5.

                  Sauf qu'au sein du même branche, l'ABI et l' API sont conservé.
                  Un logiciel conçu en 5.1 fonctionne encore aujourd'hui en 5.7 aujourd'hui.

                • [^] # Re: GTK+4

                  Posté par . Évalué à 7.

                  En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
                  Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)

                  Pas vraiment. Ou alors j’ai mal compris le nouveau modèle. De ce que je comprends du nouveau modèle GTK+, on s’autorise à casser les APIs tous les 3 ans, on ne maintient plus les anciennes.

                  La notion de LTS dans Qt est assez différente : elle consiste juste à maintenir les correctifs de sécurité, sans aucune évolution fonctionnelle, pendant 3 ans. Mais la version 5.7, sortie après, de même que la 5.8, garderont la compatibilité source et binaire. Par contre, elles vont pouvoir, par exemple :
                  * supprimer le support d’anciens compilateurs (la 5.7, typiquement, requiert un compilateur c++11, ce qui n’est pas le cas de la 5.6).
                  * supprimer le support de certains environnements (windows CE si je ne me trompe pas).

                  Pour te donner un aperçu de la durée de vie des APIs sous Qt, Qt3 est sorti en 2001, Qt4 en 2005, Qt5 en 2012. Qt6 devrait sortir en 2018. On est donc plutôt à 5 ans entre chaque changement d’API non compatible, sachant que les versions sont maintenues en parallèle (Qt 4.8.7, normalement la dernière de Qt4, est sortie en mai 2015, soit 10 ans après la sortie de Qt4). Il faut bien voir qu’une appli conçue pour Qt4.0.0 fonctionne encore avec Qt4.8.7, sorti 10 ans après.

                  Si le nouveau modèle GTK+ correspond bien à ça (c’est à dire que la branche 4 sera maintenue bien au-delà de l’apparition de la branche 5), alors c’est une excellente nouvelle.

                  Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                  • [^] # Re: GTK+4

                    Posté par (page perso) . Évalué à 7.

                    Dans le cas de la vieille branche GTK+ 2.x, dont la dernière grosse version, la 2.24.0, était sortie en 2011, on peut constater qu'elle est toujours maintenue et que la dernière révision en date est sortie il y a seulement quelques jours (2016-09-09), en apportant tout de même un certain nombre de correctifs.

      • [^] # Re: GTK+4

        Posté par (page perso) . Évalué à 3.

        Sur l'annonce officielle, il est écrit qu'une nouvelle version majeure de GTK+ aura lieu tous les 2-3 ans.

        Si la période est plus longue, ça risque d'être plus difficile de porter du code à la nouvelle version. Si la période est plus courte, les mainteneurs de GTK+ ont plus de versions à maintenir. Donc 2-3 ans est un certain compromis. 2 ans est déjà appliqué dans d'autres projets : Debian (plus ou moins), Ubuntu LTS, …

        De manière générale, quand quelque chose est pénible/difficile (ici porter son code à une nouvelle version de GTK+), il vaut mieux le faire plus souvent. Voir cet article de Martin Fowler.

        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # Génial

    Posté par . Évalué à 10.

    Les gars de Gnome font un travail fantastique !

  • # hum ?

    Posté par . Évalué à 10.

    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.

    J'ai bien dû relire plusieurs fois cette phrase pour m'assurer que je en la comprendrait tout simplement pas (et non ce n'est pas « satisfecit » qui me pose problème).

    « Un développeur de Fichier (ex-Nautilus) se félicite du regain d'activité depuis un an sur le développement de ce dernier. » c'était trop simple ?

    Pour décrire un peu plus l'article, il est dit qu'il y a un an, il était le seul contributeur alors que maintenant ils sont 5. Ils vont maintenant jusqu'à contribuer à gtk+.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: hum ?

      Posté par (page perso) . Évalué à 7.

      Tu étais où pendant la préparation de la dépêche, hum ?

      • [^] # Re: hum ?

        Posté par . Évalué à 8.

        À mon court d'aquaponey !

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: hum ?

        Posté par . Évalué à 10.

        Pour être un peu plus sérieux. Je veux bien faire de la relecture, mais je ne vois pas comment le faire.

        J'ai bien accès aux dépêches dans l'espace de rédaction, mais il m'est assez difficile de distinguer la dépêche sur la sortie de GNOME 3.24 qui est vide et va encore beaucoup changer, d'une dépêche déjà assez mature pour être relue ou d'une dépêche qui moisie depuis plusieurs années. Je ne vais pas faire du pooling pour repasser fréquemment voir comment évolue chaque dépêche.

        Faut bien voir par exemple ici, cette dépêche ne m'intéresse pas. Je n'utilise pas Gnome et son évolution ne me concerne pas. J'ai lu la partie sur gtk+ qui m'intéresse et je me suis un peu attardé pour tomber sur ce passage. Je me suis donc permis de faire une remarque.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Wayland et gestion des couleurs ?

    Posté par . Évalué à 8.

    Bonjour,
    Et tout d'abord, merci pour le travail abattu pour cette dépêche, bravo !

    Depuis 2/3 versions de Fedora, j'utilise RedShift, et j'en suis très content. Avoir le température de l'écran qui s'ajuste automatiquement à l'heure (et donc approximativement à la lumière) de l'endroit où je me trouve, je trouve ça vraiment très agréable.

    Mais, ça ne marche pas sur Wayland. Il paraîtrait que ce genre de fonctionnalités serait géré directement par Gnome, une info là dessus ?

    Merci.

  • # Proposition de correction

    Posté par . Évalué à 4. Dernière modification le 29/09/16 à 10:53.

    Merci pour cette dépêche intéressante et bien illustrée.

    J'ai cependant une proposition de correction dans la phrase suivante : 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 versatiles --> polyvalents ? variés ?

    Versatile s'applique à une personne, qui change souvent d'opinion.

    • [^] # Re: Proposition de correction

      Posté par (page perso) . Évalué à 2. Dernière modification le 29/09/16 à 12:33.

      Hmm… c'est moi qui suis coupable de ce mot là. Ensuite perso je l'utilise aussi pour des choses. D'ailleurs le Wiktionnaire a plusieurs définitions, dont une générique: "Qui est sujet à tourner, à changer."

      Bon ceci dit, on peut changer. Dans tes 2 propositions, "variés" serait plus le sens. Le fait est que les tablettes ont parfois des boutons, parfois non, parfois à gauche ou à droite (en fait souvent on peut tourner la tablette ou simplement bouger les boutons, lié à un mode "ambidextre"), parfois en haut (j'ai une vieille bamboo avec boutons en haut), avec un nombre indéfini, des fonctions le plus souvent indéfinies aussi, et des formes variées (bouton simple, roue…).
      Alors qu'une souris, dans 99% des cas, c'est un bouton à droite, un à gauche, et en général une roulette (voire un bouton pour de vieux modèles) au milieu. Le tout a des fonctions assez définis par l'usage commun depuis pas mal d'années maintenant. Et basta!

      C'était là le sens que je donnais à "versatile".
      Bon peut-être que "polyvalents" marche aussi ceci dit. Je vois que Zenitram le propose aussi plus bas.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Un avis

    Posté par . Évalué à 9. Dernière modification le 29/09/16 à 11:17.

    Je boude sur gnome-photos et gnome-document sur lesquels il me semble plus simple d'utiliser nautilus (pardon Fichier). Vidéos (anciennement Totem) à été foiré presque complètement, je l'ai remplacé depuis un moment par gnome-mplayer, même que Musique par Rhytmbox.
    Je comprend la philosophie derrière de penser "bibliothèques", mais il ne faudrait pas pour autant négliger les besoins standards que l'on attend de ces programmes. Par exemple avec Totem, il est impossible d'ouvrir un fichier. je dois l'ajouter à la vidéothèque plus la lire. Il a en plus pas mal perdu de fonctionnalités par rapport à sa version 2.*.

    Inclure des outils de manipulation d'archive dans Fichier est mauvais, vraiment. On a File-roller comme gestionnaire d'archive, c'est lui que l'on utilise pour cela. Permettre une meilleure communication entre les deux serait un meilleur départ.

    La seule chose qui me sert dans cette version et que l'article n'a pas mentionné, concerne une mise à jour de polari (le client IRC), qui permet désormais d'enregistrer les mots de passe. J'aurais préféré y voir un lien avec gnome-online-account plutôt qu'une gestion isolée mais bon.. .

    Je reste très satisfait de gnome en général, sa principale force est la conception d'interface intuitive et agréable qui répondent à l'essentiel des besoins. L'utilisant au quotidien je ne peux plus m'en passer :).

    Pour des développeurs gnome qui me liront, je souhaitera vraiment voir seahorse débogué sur la partie ssh/pgp, notamment au niveau des générations des clés, pour les futures versions. On se débrouille en cli bien sur, mais le faire en gui serait sympa également.

    Je vous ai fais un don de 50€, bonne continuation !

    • [^] # Re: Un avis

      Posté par . Évalué à 8.

      Inclure des outils de manipulation d'archive dans Fichier est mauvais, vraiment.

      Pourquoi ?

      Je trouve assez logique de retrouver la gestion de fichiers au sein d'une archive identique à la gestion de fichiers ailleurs.

      Je dis j'utilise ni l'un ni l'autre, je pose la question par curiosité.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Un avis

        Posté par . Évalué à 0.

        A première vue, oui ça semble logique. Mais si on s'en tiens à la philosophie UNIX qui consiste à dire "un besoin vaut un programme", ça reste un mauvais choix.
        Imaginons que je souhaite remplacer Nautilus par autre chose (Thunar, même si c'est improbable), et ben zut je perd les capacités de manipulation d'archive.

        C'est un choix, mais comme Gnome semble vouloir mettre en avant cette modularité https://en.wikipedia.org/wiki/GNOME_Core_Applications , autant rester sur la même voie.

        Après cela n'empêche pas d'avoir quelques raccourcis d'actions tel que l'extraction dans le répertoire courant, ou la création d'archives.. au sein de nautilus à travers un plugin, mais alors basé entièrement sur l'api de file-roller.

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 5.

          Euh, ils ont pas enlevé file roller hein ;)

          • [^] # Re: Un avis

            Posté par (page perso) . Évalué à 2.

            Mais les développeurs GNOME risquent de ne plus maintenir File Roller.

            « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 2.

          Nautilus utilise la bibliothèque gnome-autoar pour compresser/décompresser les archives. Peut-être que File Roller utilise la même bibliothèque, je ne sais pas.

          Pour la raison d'avoir intégré ça à Nautilus, voir le post de Carlos Soriano:

          You may be aware that we have been using File Roller since forever to handle compressed files. However, this makes integration with Nautilus none. It misses the progress report integration, undo, redo, and possibility to close the application while the operation continues.

          « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Un avis

        Posté par (page perso) . Évalué à 6.

        Sur Windows les archives sont affichées comme des dossiers dans l'explorateur. c'est ça l'inclusion dont on parle ?

        C'est pas forcement débile, mais ça donne des comportements difficiles à comprendre pour les utilisateurs. J'ai plusieurs fois eu le cas avec des clients qui ne comprennent pas pourquoi une page html ne s'affiche pas correctement (ouverte depuis un zip l'explorateur la décompresse dans un répertoire temporaire puis l'affiche dans le navigateur, mais sans décompresser les dépendances).

      • [^] # Re: Un avis

        Posté par (page perso) . Évalué à 2.

        Je crois comprendre qu'à présent si on clic-clic ça se décompresse. Avec File Roler on avait un aperçu de l'archive pour se décider, voire n'en décompresser qu'une partie.

        • [^] # Re: Un avis

          Posté par . Évalué à 2.

          D'ailleurs si quelqu'un sait si on peut revenir à l'ancien comportement et comment y revenir, je suis preneur?
          Parce que la décompression automatique m'agace au plus haut point. Si on a une archive compressée c'est pour prendre moins de place et ce n'est parce que on veut aller voir dedans que l'on veut la décompresser de manière permanente.

          Bon on est vendredi, donc j'y vais:
          Bref si les dev de Gnome dépensaient leur énergie à nous permettre de faire les choses comme on le veut plutôt que d'essayer de penser à notre place et de nous imposer des comportements qui ne conviennent pas, ça serait bien mieux …

          • [^] # Re: Un avis

            Posté par . Évalué à 1.

            Suffit de lire la dépêche

          • [^] # Re: Un avis

            Posté par . Évalué à 8. Dernière modification le 01/10/16 à 16:37.

            Si on a une archive compressée c'est pour prendre moins de place et ce n'est parce que on veut aller voir dedans que l'on veut la décompresser de manière permanente.

            La décompression « transparente » dans le navigateur de fichier ne va décompresser l’archive que si on navigue dedans… Je ne parle pas des « dossiers compressés » de Windows mais bien du simple fait de cliquer sur un fichier zippé. Qu’un navigateur de fichiers offre cette possibilité d’accéder rapidement, en lecture seule, à l’archive ça peut être pratique.

            Cela dit sous Windows je ne m’en sers pas car ça ne supporte qu’un nombre restreint de formats et ça va tout aussi vite de faire clic droit > ouvrir avec 7-zip…

            D’ailleurs c’est assez marrant, le navigateur de fichiers de 7-zip permet non seulement de naviguer dans à peu près n’importe quel type d’archive compressée mais aussi dans le système de fichier, comme un navigateur de fichier lambda. J’ai eu à naviguer dans des dossiers comprenant pléthore de fichiers, 7-zip est plus rapide et ne se vautre pas parce qu’il y a trop de fichiers :) Je précise que par « vautrer » je ne dis pas que Explorer plante, mais bon, quand au bout de cinq minutes il mouline et a toujours rien affiché… _o_

    • [^] # Re: Un avis

      Posté par . Évalué à 1.

      Inclure des outils de manipulation d'archive dans Fichier est mauvais, vraiment. On a File-roller comme gestionnaire d'archive, c'est lui que l'on utilise pour cela. Permettre une meilleure communication entre les deux serait un meilleur départ.

      On t'invite donc à désactiver la fonctionnalité comme précisé. Perso j'aime bien, le comportement par défaut est perturbant pour l'utilisateur Michu (même si ce n'est pas mieux ailleurs !)

      • [^] # Re: Un avis

        Posté par . Évalué à 0.

        Ce que je n'ai pas hésité à faire :)
        C'est simplement l'idée d’ajouter des capacité de manipulation d'archives à nautilus indépendamment de file-roller qui ne me plaît guère. Ce qui me fait craindre à l'avenir est un possible abandon de ce dernier.

      • [^] # Re: Un avis

        Posté par . Évalué à 0.

        Et on désactive comment parce que malgré la légendaire intuitivité de Gnome je n'ai pas trouvé. J'ai essayé d'affecter file-roller à l'ouverture des archives mais sans succès …

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 8.

          Tu parles d’aller dans le menu Préférences de Fichiers > onglet comportement > section Fichiers compressés ?

          Préférences Fichiers

          En quoi c’est moins intuitif qu’un menu de préférences classique pour une application quelconque ?

          • [^] # Re: Un avis

            Posté par . Évalué à 1.

            Alors là, je suis quasi sur que je n'ai pas ça sur ma version. C'est le premier endroit où je suis allé chercher.
            Mais sur debian testing tout n'est pas encore passé en 3.22 certaines parties sont encore en 3.21.92 peut-être est-ce lié ?

            • [^] # Re: Un avis

              Posté par (page perso) . Évalué à 2.

              Je suis sous sid qui a la version 3.22 de nautilus, par contre testing est en 3.21.91.1-1

    • [^] # Re: Un avis

      Posté par (page perso) . Évalué à 1. Dernière modification le 29/09/16 à 14:33.

      Pour les vidéos, normalement, tu n'es pas « censé » avoir besoin de les ajouter manuellement. Totem va trouver automatiquement toutes tes vidéos du dossier Vidéos et des autres dossiers que t'aurais pu vouloir ajouter (Paramètres GNOME, Rechercher, petite roue crantée en bas à droite…). C'est la même chose pour Photos et autres applications GNOME, qui tentent le plus possible de faire disparaître la notion de fichiers et autres arborescences aux utilisateurs.

      • [^] # Re: Un avis

        Posté par . Évalué à 7.

        Sauf que ça te coupe de beaucoup de cas d’utilisation. Typiquement, lire une vidéo sur un dossier réseau. Je comprends la logique, mais elle ne correspond pas à mes cas d’utilisation.

        Accessoirement, certaines de ces applications sont plus des jouets qu’autre chose. Dans le sens où elle ne fonctionnent pas dans la vraie vie (essaie d’utiliser Music avec une collection conséquente, par exemple…).

        J’utilise gnome3, et j’aime beaucoup l’ergonomie du shell, mais les choix faits pour les nouvelles applications me laissent un peu dubitatifs.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 1.

          Je pense que les applications de base (Musique, Vidéos, Photos…) se destinent surtout aux utilisateurs débutants, qui sont vite perdus. Pour de la musique, un utilisateur avancé utilisera plutôt Lollypop, Rhythmbox, Audacious… ce ne sont pas les choix qui manquent. Même chose pour la vidéo. GNOME MPV proposera bien plus d'options, dont le fait de pouvoir ouvrir par soit-même n'importe quelle vidéo :p

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 5.

          Sauf que ça te coupe de beaucoup de cas d’utilisation. Typiquement, lire une vidéo sur un dossier réseau.

          Note que la plupart des lecteurs vidéo fournis dans un OS ne permettent pas cela.
          Le but des applications GNOME n'est pas de remplacer les applications puissantes comme VLC ou Firefox dans leur catégorie. C'est de répondre à un besoin de base dans une ergonomie contrôlée, cohérente et épurée.

          Accessoirement, certaines de ces applications sont plus des jouets qu’autre chose. Dans le sens où elle ne fonctionnent pas dans la vraie vie (essaie d’utiliser Music avec une collection conséquente, par exemple…).

          Music a beaucoup progressé en terme de performances. Aujourd'hui c'est utilisable dans ma collection (1500 morceaux) ce qui n'était pas le cas il y a peu.

          Le soucis est que les applications Documents, Photos et Music reposent sur tracker qui est plutôt peu maintenu alors qu'il a encore de grosses lacunes.

          • [^] # Re: Un avis

            Posté par (page perso) . Évalué à 3.

            Dans le cas de Musique, ce n'était pas tracker le souci. Comme l'indiquait Georges Basile Stavracas Neto sur son blog, « Let me be crystal clear: Tracker is fast as hell. GNOME Music was slow to death. Retrieving the list of songs from Tracker takes about 0.25 second, putting the songs into a window and presenting it used to take ~85 seconds. Yes, that’s right, 340x slower. »

            • [^] # Re: Un avis

              Posté par (page perso) . Évalué à 2.

              Mwai, je viens de tester la 3.22…

              Sur une grosse collection, c'est encore très lent (5 secondes pour commencer à afficher les albums)… Et en plus il ne m'affiche aucune pochette en essayant de les choper sur Spotify (pas de net sur cette machine). Sûrement un bug parce que ça fonctionnait avant.

              Bref, je reste convaincu que pour une requête simple: "je veux les fichiers audio", tracker est rapide mais dès que tu lui demandes des trucs plus complexes via les ontologies, ben tu ne peux avoir les perfs d'une base SQL avec une schéma bien pensé…

              Bref je suis déçu de voir que ces problèmes là ne sont pas réglés, je pense surtout que les devs de Gnome Music n'ont que des petites collections et donc ne sont pas emmerder par ces soucis…

              • [^] # Re: Un avis

                Posté par . Évalué à 1.

                Sur une grosse collection, c'est encore très lent

                Qu'est-ce que tu appelles grosse collection ?

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 3.

          Je viens de vérifier la lecture de vidéos sur le réseau. Là où c'est génial (et je me demande pourquoi toutes les applications GTK+ ne le proposent pas), c'est que le sélecteur de fichiers reconnaît tous les signets que j'ai configuré dans Nautilus, ce qui inclut mes serveurs auxquels j'accède par SFTP. Et tout comme dans Nautilus, grâce à GVFS, je peux sans problème lire le contenu comme si c'était en local.

          Notons que Totem propose également un greffon Grilo pour la Freebox. Je peux donc lire le contenu de cette dernière, de mes serveurs, des partages Windows… sans avoir à me prendre la tête à configurer quoi que ce soit.

          Ça propose donc par défaut le contenu des dossiers de la norme XDG user directories, mais on peut sans problème ajouter de nouveaux dossiers ou lire du contenu distant.

        • [^] # Re: Un avis

          Posté par (page perso) . Évalué à 3.

          Sauf que ça te coupe de beaucoup de cas d’utilisation. Typiquement, lire une vidéo sur un
          dossier réseau. Je comprends la logique, mais elle ne correspond pas à mes cas >d’utilisation.

          Tu lance nautilus, tu vas dans ton dossier réseau et tu cliques dessus, ça se lance dans totem…

      • [^] # Re: Un avis

        Posté par (page perso) . Évalué à 2.

        Après Windows qui ne reconnaît les fichiers que par leur extension, on a maintenant des outils qui reconnaissent les fichiers en fonction du dossier dans lequel ils sont rangés? Mais on arrête pas le progrès ma parole :)

        • [^] # Re: Un avis

          Posté par . Évalué à 7.

          Pfff, Windows Vista le faisait déjà en 2006.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Un avis

        Posté par . Évalué à 4.

        C'est la même chose pour Photos et autres applications GNOME, qui tentent le plus possible de faire disparaître la notion de fichiers et autres arborescences aux utilisateurs.

        Et c'est bien là leur principal défaut !!!
        Du coup je n'utilise plus ni l'un ni l'autre. C'est trop prise de tête à utiliser.

  • # Faux-ami

    Posté par (page perso) . Évalué à 5. Dernière modification le 29/09/16 à 12:13.

    oui oui grammar-nazi.

    car ce sont des périphériques très versatiles

    Des périphériques qui changent facilement d'opinion? Ca fait bizarre.
    J'imagine que c'est un anglicisme, versatile (en) voulant dire polyvalent, qui semble mieux correspondre à la phrase ("car ce sont des périphériques très polyvalents").
    (et : oui, je me suis demandé ce que la phrase voulait dire pendant un moment, car je l'ai lu avec le français en tête vu qu'il n'y avait pas d'italique par exemple pour signifier que c'était de l'anglais)

    • [^] # Re: Faux-ami

      Posté par (page perso) . Évalué à 3.

      Corrigé, merci.

    • [^] # Re: Faux-ami

      Posté par . Évalué à 4.

      oui oui grammar-nazi.

      Ta correction n'a rien à voir avec la grammaire, il faudrait plutôt dire vocabulary-nazi.

      • [^] # Re: Faux-ami

        Posté par . Évalué à 3.

        La Larousse définit la grammaire ainsi :

        Ensemble des règles qui président à la correction, à la norme de la langue écrite ou parlée

        Autrement dit, le concept de grammaire englobe celui de « correction du vocabulaire », choisir les bons mots fait partie intégrante du respect de la norme d’une langue.
        ```

  • # Wayland et copier-coller à la souris

    Posté par (page perso) . Évalué à 6.

    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.

    Est-ce à dire que le copier-coller à la souris a finalement été implémenté ? Parce que sans ça, il y a toute une catégorie d'utilisateurs, notamment de développeurs, qui ne passeront pas à Wayland.

  • # Pointeurs multiples

    Posté par (page perso) . Évalué à 8.

    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.

    D'où sort cette affirmation ? Avec XInput, on peut tout à fait avoir plusieurs pointeurs, et plusieurs claviers d'entrée bien distincts ! Ça se comporte certainement de façon étrange pour des logiciels qui ne sont pas prévus pour cela, mais côté serveur X, c'est prêt.

    • [^] # Re: Pointeurs multiples

      Posté par (page perso) . Évalué à 5.

      Salut,

      Ok ben je ne savais pas qu'il y avait cette fonctionnalité dans X, mais donc elle est désactivée par défaut dans toutes les distributions? Je ne l'ai jamais vécue (et on utilise des tablettes, etc.) donc je suppose que c'est le cas. Or une fonction désactivée partout (et pire pas activable facilement, en tous cas, je ne crois pas avoir jamais vu une telle option dans un panneau de configuration d'un quelconque système Linux), c'est comme si cela n'existe pas malheureusement.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Pointeurs multiples

        Posté par (page perso) . Évalué à 10.

        Ce n'est pas tant que cette option soit désactivée, c'est simplement que ça n'a pas de sens sans réglage.

        Il y a une notion de pointeurs et de claviers maîtres, qui sont affichés et exposés aux logiciels. Grossièrement, un pointeur maître, c'est une flèche à l'écran, et un clavier maître, c'est un curseur de saisie.

        Ces périphériques maîtres sont associés par deux, un pointeur et un clavier maître à chaque fois.

        À côté de cela, il y a les périphériques réels, dits asservis, qui sont tous attachés à un périphérique maître. Quand on bouge une souris physique, ça envoie les événements correspondants au pointeur maître auquel elle est attachée. De même, quand on appuie sur une touche d'un clavier, ça envoie l'événement correspondant au clavier maître auquel il est attaché.

        Par défaut, il y a une seule paire de périphériques maîtres, donc un pointeur maître et un clavier maître associé, et tous les périphériques réels y sont attachés, afin que quand on bouge un souris, ça bouge le pointeur à l'écran, et que quand on tape sur un clavier, ça écrive dans la zone de saisie qui a le focus. Par exemple, chez moi :

        % xinput
        ⎡ Virtual core pointer                        id=2    [master pointer  (3)]
        ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
        ⎜   ↳ Logitech USB-PS/2 Optical Mouse           id=10   [slave  pointer  (2)]
        ⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
            ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
            ↳ Power Button                                id=6    [slave  keyboard (3)]
            ↳ Power Button                                id=7    [slave  keyboard (3)]
            ↳ Logitech USB Keyboard                       id=8    [slave  keyboard (3)]
            ↳ Logitech USB Keyboard                       id=9    [slave  keyboard (3)]
            ↳ Yubico Yubikey NEO OTP+CCID                 id=11   [slave  keyboard (3)]

        À partir de là, on peut s'amuser à détacher des périphériques physiques : leurs événements ne sont alors plus transmis nulle part. Attention, c'est un bon moyen de se blo

        On peut créer une nouvelle paire de périphériques maîtres, et y attacher des périphériques (si on a effectivement plusieurs souris, tablettes graphiques, joysticks et claviers, sinon ça ne sert à rien) : à l'écran, ça donne un pointeur supplémentaire, et potentiellement un focus de saisie supplémentaire.

        Pour en revenir sur ce que je disais au début, en fait XInput est activé par défaut, seulement avec la seule configuration raisonnable et non troublante : tous les pointeurs et tous les claviers sont fusionnés.

        • [^] # Re: Pointeurs multiples

          Posté par (page perso) . Évalué à 1.

          Du coup, des infos sur la façon de gérer le focus clavier en fonction de la position des pointeurs de souris sous GNOME/Wayland? Je suppose qu'il n'y a pas de "Focus Follows Mouse" et qu'il faut absolument cliquer sur un contrôle pour lui donner le focus clavier?

          • [^] # Re: Pointeurs multiples

            Posté par (page perso) . Évalué à 2.

            Je suppose qu'il n'y a pas de "Focus Follows Mouse"

            Argh, si c'est le cas, décidément, ce n'est pas demain que je passerai à Wayland. Mais bon, ça doit dépendre du compositeur ça, et de toute façon, si je passe à Wayland, ce sera pour un compositeur pavant, pas pour celui de Gnome. :-)

          • [^] # Re: Pointeurs multiples

            Posté par . Évalué à 0.

            Tu peux focus une fenêtre lorsque la souris passe dessus si j'ai bien compris la question (via gnome tweak tools)

            • [^] # Re: Pointeurs multiples

              Posté par . Évalué à 1.

              La question est: quand tu as plus d'un curseur de souris, lequel est pris en compte pour le focus ?

              • [^] # Re: Pointeurs multiples

                Posté par . Évalué à 1.

                Il serait logique que le focus soit différent pour chaque pointeur, et comme on a déjà la notion de paire (pointeur/clavier), les différents claviers auraient un focus différent. Est-ce que c'est possible ? C'est une question de gestionnaire de fenêtres il me semble.

        • [^] # Re: Pointeurs multiples

          Posté par . Évalué à 2.

          Si je comprends, il serait assez facile (comprendre : yaka configurer) de dissocier la souris, le touchpad et le "clito entre les touches" d'un ordinateur portable, pour avoir jusqu'à 3 curseurs de souris ?

  • # Flatpak

    Posté par . Évalué à 5.

    Je trouve l'idée très bonne, mais :
    En regardant sur la page du projet on voit "Runtime (shared)" mais tout est dans une sandbox du coup la question que je me pose est : "Est ce que "Flatpak" fait un packaging à la windows ? c'est à dire qu'il embarque toutes les bibliothèques nécessaires à chaque fois ? Tout bien réfléchi ça n'a pas de sens du coup de mettre 'shared' sauf si c'est des .so (shared object).
    Et si ces bibliothèques sont bien partagées entre les différents logiciels sur le système, quid de celles représentées non partagées ? et si un autre logiciel s'installe et dépend aussi d'une bibliothèque non partagé, devient elle partagée à son tour ?
    Quelqu'un a t il un retour sur ce système de package ?

    Sinon super la dépêche ça me donne envie de réessayer Gnome un de ces quatre :-)

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Flatpak

      Posté par (page perso) . Évalué à 6.

      Plusieurs applications peuvent utiliser le même runtime, le runtime est partagé. Si une application a besoin d'une bibliothèque qui n'est pas présente dans le runtime, cette bibliothèque doit être "bundlée" avec l'application.

      Il peut y avoir plusieurs runtime bien entendu : il y a le runtime freedesktop.org, un runtime GNOME, un runtime pour Qt/KDE est en développement, et certaines entreprises ont leur propre runtime. Et il y a généralement plusieurs versions pour un certain runtime : GNOME 3.20, GNOME 3.22, etc.

      L'énorme avantage, pour un développeur d'application, c'est que le développement et les tests sont faits avec un runtime précis (et une version précise). Par exemple le runtime GNOME 3.22. Quand GNOME 3.24 sortira, l'application pourra toujours utiliser le runtime GNOME 3.22, donc il y a beaucoup plus de garanties que l'application fonctionnera toujours bien (càd les utilisateurs utilisent la même chose que ce que les développeurs ont utilisé).

      Certes, ça utilisera plus de RAM puisque toutes les applications n'utiliseront pas la même version du runtime. Mais de la RAM, les ordinateurs récents en ont assez, et avoir des applications moins buggées (et qui demande moins de travail pour les développeurs) semble être plus important.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Flatpak

        Posté par . Évalué à 2.

        On dirait Docker avec ses layers :)

        On en est peut-être pas si loin…

    • [^] # Re: Flatpak

      Posté par . Évalué à 2.

      J'ai un peu testé car l'idée me paraît intéressante quand on voit la misère que ça peut être de gérer des versions concurrente des bibliothèques.
      Cette solution est proche de ce qu'on trouve sous MacOSX ou Android. Le système fournit quelques bibliothèques de base et les applications embarquent le reste, quitte à se répéter. Et heureusement, c'est à l'opposé de windoze qui a choisi de mettre toutes les version possibles et imaginables dans un dossier système qui ne peut que grossir et finit par atteindre des Tétrachiés de bytes sans possibilité de faire le ménage.
      Reste que pour l'instant le catalogue est bien chiche par rapport à aux catalogues des grandes distributions.

      • [^] # Re: Flatpak

        Posté par (page perso) . Évalué à 4.

        Reste que pour l'instant le catalogue est bien chiche par rapport à aux catalogues des grandes distributions.

        C'est ce que les devs de Flatpak essaient de changer avec le projet Flathub, un app store multi-distro très prometteur, mais qui n'en est encore qu'à ses balbutiements.

        • [^] # Re: Flatpak

          Posté par . Évalué à 2.

          j'ai voulu essaye d'installer un truc avec flack et finalement je n'ai pas trouve. Par contre la version snap… donc si ils veulent que ca devienne le standard il va falloir se bouger les fesses sinon comme d'hab on aura de la fragmentation.

  • # personnalisable (non, là, je plaisante, en revanche) ha bon

    Posté par . Évalué à 6.

    J'ai créé un compte rien que pour ça.

    Awesome WM est personnalisable en utilisant Lua, Xmonad est personnalisable avec Haskell par contre Gnome avec le CSS et le javascript que personne utilise, c'est juste impossible de le personnaliser, c'est ça?

    J'ai mal compris? je m'énerve pour rien ?

    • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

      Posté par . Évalué à 3.

      Bien plus de monde utilise JS et CSS que Haskell ou Lua…

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

        Posté par . Évalué à 4.

        C'est bien pour cela que ça m'énerve qu'il sous-entende que Gnome n'est pas personnalisable.

        • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

          Posté par (page perso) . Évalué à 3.

          La personne capable de mettre les mains dans le cambouis pourra toujours personnaliser son environnement, quel qu'il soit. Maintenant, je pense qu'antistress faisait surtout référence au fait que GNOME se veut accessible au plus grand nombre, ce qui implique de ne pas noyer les utilisateurs sous des tonnes d'options et de possibilités, ce qui rendrait l'ensemble plus compliqué à prendre en main, tout en multipliant les causes d'erreurs potentielles (sous Windows, on ne compte plus les utilisateurs qui ont tout cassé, mais qui n'ont bien évidemment jamais touché à rien, quand on leur pose la question).

          Et cette population n'ayant pas de grandes connaissances informatiques, qui veut juste que ça fonctionne tout seul pour pouvoir faire simplement ce qu'ils ont à faire, n'ira jamais développer des extensions en JavaScript ou modifier le CSS de leur thème.

          • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

            Posté par . Évalué à 0. Dernière modification le 29/09/16 à 15:32.

            Admettons, dans ce cas là existe t il un équivalent qui soit personnalisable selon sa définition?(histoire que je puisse visualiser).

            Parce qu'en admettant que l'on utilise pas le CSS ou Javascript, en passant par gnome-tweak-tool on a quand même la possibilité de modifier pas mal de paramètres, de la même manière avec web (epiphany), tu vas sur le site d'extension, tu peux ajouter pas mal de nouvelles fonctionnalités et paramètrage supplémentaires (changer ton thème user-shell, thème gtk+, thème icon) sans avoir besoin de grandes compétences et je parle pas de gconf.

            Franchement je vois pas trop, après, j'ai aucune expérience avec Qt/Kde, peut être que là les gens ont bien plus de possibilités, mais pour moi Gnome est facilement personnalisable.

            • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

              Posté par . Évalué à -1.

              Franchement je vois pas trop, après, j'ai aucune expérience avec Qt/Kde, peut être que là les gens ont bien plus de possibilités, mais pour moi Gnome est facilement personnalisable.

              Il n'y a qu'à voir le nombre d'extensions sur le site gnome pour leur fermer la bouche.

              Qt/KDE: en gros, tu peux bouger/retirer tous les éléments d'une GUI à la souris. Avoir 40 "panel", 20millions de raccourcis, des widgets inutiles sur ton bureau, intégré n'importe quel composant (term, vue web, etc) dans une autre application KDE, etc, etc…
              Bref, celui qui a pleins de temps à perdre, s'amusera sous KDE et peut-être utilisera son ordinateur pour s'attaquer à une problèmatique qui justifia en premier lieu l'usage d'un ordinateur, enfin si il arrive à se déconnecter de /r/unixporn.

              • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

                Posté par . Évalué à 9. Dernière modification le 30/09/16 à 15:07.

                Il n'y a qu'à voir le nombre d'extensions sur le site gnome pour leur fermer la bouche.

                Depuis Gnome 3.0 j'ai gardé toutes les extensions que j'avais installé. Aujourd'hui je suis en 3.22 et les 3/4 des extensions ne sont plus utilisables…
                Les extensions c'est une sorte de miroir aux alouettes. Mais face au temps qui passe l'argument ne tient pas vraiment.

                • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

                  Posté par . Évalué à 1.

                  Depuis Gnome 3.0 j'ai gardé toutes les extensions que j'avais installé. Aujourd'hui je suis en 3.22 et les 3/4 des extensions ne sont plus utilisables…
                  Les extensions c'est une sorte de miroir aux alouettes. Mais face au temps qui passe l'argument ne tient pas vraiment.

                  Je suis vraiment curieux, qu'utilises-tu ou utilisais-tu comme extension?
                  Je suis en Gnome 3.18 et je n'en ai aucune d'activée.

                  Je suis pourtant un utilisateur avancé.

                  • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

                    Posté par (page perso) . Évalué à 3.

                    Pareil j'ai commencé à utiliser GNOME Shell avec plein d'extensions pour retrouver mes habitudes de KDEiste(windowsien) et finalement, aujourd'hui, je l'utilise sans extension, pour mon plus grand plaisir.

                    • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

                      Posté par . Évalué à 3.

                      Comment pouvez-vous survivre sans l'indispensable extension Wobbly Windows ?!???

                      https://extensions.gnome.org/extension/669/wobbly-windows/

                      Plus sérieusement, dans le TOP10 des extensions GNOME Shell il y en a de sympas :
                      - afficher dans la top bar la liste des "emplacements"
                      - afficher un menu hiérarchique des applications dans la top bar (c'est bien quand on veut découvrir les applications)
                      - choisir son thème (indispensable quand on est sous Ubuntu et qu'on veut retrouver l'apparence normale de GNOME)
                      - lancer une nouvelle instance quand on clique sur l'icone du "dock"
                      - ajouter un contrôle de Rythmbox dans la top bar

                      Et il y en a plein d'autres qui permettent de personnaliser par petites touches son bureau.

                      Le petit plus : on peut installer les extensions en un clic depuis le catalogue web :)

                      BeOS le faisait il y a 15 ans !

                      • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

                        Posté par . Évalué à -5.

                        • afficher dans la top bar la liste des "emplacements"

                        Disponible dans gnome tool tweak qui lui est dipso de base sous Ubuntu.

                        • afficher un menu hiérarchique des applications dans la top bar (c'est bien quand on veut découvrir les applications)

                        Disponible dans gnome tool tweak. Mais tu peux tout aussi bien découvrir les applications sur la vue overview et puisque les applications empaquetées respectent le standard freedesktop, tu peux taper juste le nom de la catégorie de l'application pour en avoir une selection.

                        • choisir son thème (indispensable quand on est sous Ubuntu et qu'on veut retrouver l'apparence normale de GNOME)

                        Disponible dans gnome tool tweak ou tu pars d'une installation Ubuntu Gnome.

                        • lancer une nouvelle instance quand on clique sur l'icone du "dock"

                        Depuis toujours: ctrl+click ou bouton droit=> menu contextuel => nouvelle fenêtre

                        Et prendre 2 minutes à consulter le Gnome Shell Tour. Même Apple, Android fait ça.

                        • ajouter un contrôle de Rythmbox dans la top bar

                        n'importe quelle extension supportant MPRIS mais du coup, c'est aussi une extension sur les autres bureaux.

                        Bref, ça nécessitait vraiment un fork à la Mate ou Cinnamon. :/

                        Heureusement que l'équipe Gnome ne s'est pas découragée, leur mérite n'en est que plus grand.

                        Merci d'avoir répondu, ceci dit.

        • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

          Posté par (page perso) . Évalué à 3.

          C'est moi qui suis à l'origine de cette phrase. Mon avis d'utilisateur lambda est que GNOME 3 est moins personnalisable que GNOME 2, mais ce n'est que mon ressenti.
          Je précise que je n'ai jamais connu que GNOME 2 et GNOME 3

    • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

      Posté par . Évalué à 7. Dernière modification le 29/09/16 à 15:22.

      je m'énerve pour rien ?

      Oui.

      Awesome WM est personnalisable en utilisant Lua, Xmonad est personnalisable avec Haskell par contre Gnome avec le CSS et le javascript que personne utilise, c'est juste impossible de le personnaliser, c'est ça?

      Alors il faut distinguer le moyen et la philosophie.
      La doc d'awesome, d'xmonad ou de dwm te présente de base le hacking par ces méthodes. Ce sont les seuls façon de manipuler ces gestionnaires de fenêtres. C'est compliqué. Madame Michu n'aime pas. C'est pas prêt pour le desktop. Tout ce que tu veux, mais si tu les utilise tu accède nécessairement à cette façon de configurer.

      Pour des DE comme gnome, XFCE, KDE,… tu as un tas de niveaux de configuration (typiquement celle intégrée - qui te demande par exemple si tu veux toujours aller sur le web avec firefox -, celle dans les paramètres de chaque application, celle dans les paramètres globaux, celle dans les outils à installer à coté - oui tweak tool c'est à toi que je pense -, la base dconf et enfin mettre les mains dans le cambouis). Le fait que ce soit aussi loin le rend inexistant pour une bonne part des utilisateurs et fais que le découpage n'est pas forcément parfait (certains trouvant que tel bidouille devrait se trouver dans tel niveau plutôt qu'un autre notamment parce que ça ne plaît jamais de passer au niveau suivant de configuration).

      Du coup, quand tu lis :

      c'est juste impossible de le personnaliser

      Essaie de comprendre « ce n'est pas simple à personnaliser » :)

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

        Posté par . Évalué à 2.

        c'est juste impossible de le personnaliser
        ```Essaie de comprendre « ce n'est pas simple à personnaliser » :)
        

        Ça fait quand même une sacrée différence. Mais bon vu comme ça d'accord.

        • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

          Posté par . Évalué à -4.

          Ne cède pas à Barmic. :)
          D'autant que Gnome-tweak Tool est le niveau "intermédiaire" dont il parle.

          Antistress voulait bien dire "impossible de le personnaliser", comme toutes les simplifications qu'il fait en tant que bon extrêmiste libriste qu'il est. Gentil certes mais extrêmiste quand même. :p

          Je suis utilsateur de Gnome mais j'ai plutôt des complaintes envers certaines application du projet (bijiben, totem, rythmbox) que du bureau et de ses outils en tant que tel.

    • [^] # Re: personnalisable (non, là, je plaisante, en revanche) ha bon

      Posté par (page perso) . Évalué à 7.

      un jour j'ai cherché comment changer la couleur de la barre de titre de la fenêtre active de gnome (parce qu'en bi-écran il est très facile de faire un ctrl-w dans la mauvaise fenêtre et de fermer le mauvais onglet, parfois très embêtant)

      je n'ai pas trouvé de thème qui fasse ça selon mes goûts

      sachant qu'une bonne partie de l'interface est en css/html/js (?) et étant développeur web, je me suis dit que j'allais tenter le coup

      quelques heures de recherche plus tard j'ai renoncé, je n'ai pas réussi à trouver de documentation sur le sujet (ou bien de la documentation qui ne s'appliquait plus à une version récente de gnome)

      je continue à faire des control-w dans les mauvaises fenêtres….

      Envoyé depuis mon Archlinux

  • # /242

    Posté par (page perso) . Évalué à 6.

    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.

    Normal people: « Ô misère /o\ comme si ce n'était pas assez compliqué comme ça… »

    Geek people: « On pourrait donc imaginer de nouvelles manières de geeker où un geek pourrait […] On pourrait même … »

    Adhérer à l'April, ça vous tente ?

  • # icones

    Posté par . Évalué à 3.

    Petite question à tous: suis-je le seul à ne plus avoir d'icones dans les menus des logiciels?

    • [^] # Re: icones

      Posté par (page perso) . Évalué à 3.

      Ça fait déjà un bout de temps que les icônes dans les menus ont été dépréciés.

      Tu peux trouver une méthode ici pour les récupérer si tu veux absolument des icônes partout. En espérant pour toi que cette méthode marche toujours (le lien date de 2013):
      https://ask.fedoraproject.org/en/question/23116/how-to-fix-missing-icons-in-program-menus-and-context-menus/

      Je crois que la logique actuelle est de s'éloigner des icônes partout, pour tout. C'est joli, coloré (ou pas), mais ça aide pas beaucoup à la compréhension au final, surtout avec des actions compliquées. Il y a des cas où c'est utile, pour des questions de place dans l'UI notamment, mais parfois cela porte surtout à confusion (qui ne s'est jamais demandé "à quoi peut bien servir cette icône dans un logiciel?" et être obligé de tester pour comprendre?). Le texte par contre ne porte jamais (ou plus rarement en tous cas) à confusion.
      Alors quand y a déjà du texte de toutes façons (comme dans un menu), la question est aussi: l'icône apporte-t-elle quelque chose de plus? Ou bien ne fait-elle que prendre de l'espace?
      Pour la même raison, les boutons qui ont du texte n'ont plus l'icône à côté par défaut (en gros, c'est soit texte, soit icône, mais les deux ensemble, ça sert pas à grand chose).

      Sans compter aussi l'effet "PlaySchool" que peut donner un logiciel quand y a des icônes partout.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: icones

        Posté par . Évalué à 10.

        Les icônes aident énormément à utiliser sa mémoire visuelle tout de même.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: icones

          Posté par . Évalué à 5.

          C'est comme les fichiers, c'est has been.

          • [^] # Re: icones

            Posté par . Évalué à 4.

            Faudrait pas me rendre moins disruptif que je ne le suis :)

            Les fichiers c'est une façon de représenter des données, mais il y a pleins d'autres façon de le faire. Je ne sais pas comment font les autres OS mobiles, mais il y a une volonté de cacher le stockage arborescent sur Android. Oui ça choque quand on est habitué à mettre les petits fichiers dans les grands dossiers, mais ça a l'air de convenir à pas mal de monde, non ? (attention j'ai pas dis que c'était parfait, hein ? l'arborescence aussi ce n'est pas parfait loin de là)

            AMHA ce qui pose problème (la disparition des fichiers) c'est le coté hybride. Tout gérer par fichiers arborescents sauf dans certains endroits.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: icones

              Posté par (page perso) . Évalué à 8.

              AMHA ce qui pose problème (la disparition des fichiers) c'est le coté hybride. Tout gérer par fichiers arborescents sauf dans certains endroits.

              En fait je vois 2 choses qui gênent vraiment:

              Le changement d'applications

              Ce n'est pas problématique de savoir où sont ses photos par exemple du moment qu'un autre logiciel puisse aussi les utiliser et en plus sans perte de fonctionnalité (cad si c'était de la gestion par tags, etc. on veut retrouver ses tags dans l'autre logiciel). Dans les faits, ce n'est souvent pas le cas et on le voit bien sous Android: des photos faites dans un logiciel "caméra" ne sont pas forcément visible dans un autre logiciel "caméra". C'est pénible de devoir naviguer entre les logiciels pour retrouver une photo (je connais des gens qui utilisent plusieurs logiciels de caméra parce qu'ils proposent des filtres différents, etc.).

              Ceci implique d'avoir un standard de gestion des images qui serait alors commun à tout logiciel de gestion des images et permettrait donc de passer d'une appli à l'autre sans avoir à "bouger" des données d'une application à l'autre, donc sans connaissance interne des fichiers. Mais il y a toujours des limites ici aussi, car un standard implique aussi de prendre en compte les spécificités d'un type de fichier donc il faut un standard par type de fichiers: un standard pour les images, un pour les films, un pour la musique, un pour les livres, un pour les documents comptables, un pour ceci, un pour cela… or il y a toujours un type de document trop spécifique car il existe tellement de spécialités donc de types de fichier incongru. Gérer des standards de "où et comment on range tel type de fichier" devient une liste de standards qui grandit à l'infini et avec laquelle il faut toujours se mettre à jour.

              La sauvegarde/Le déplacement de fichiers

              Le truc classique, on a des images sur son portable, on veut les mettre sur l'ordinateur. Par exemple en branchant un smartphone, l'ordi propose souvent l'import d'images automatique, qui est totalement dans l'esprit "disparition du concept de fichiers". Mais dans le portable, y a aussi des vidéos. Il faut donc un import des vidéos séparés. Et y a d'autres types de fichiers qu'on a pu recevoir par email ou autre. Faut donc des imports pour eux aussi.
              Au final, on se retrouve avec le problème des standards, mais c'est pire car on peut pas se permettre de passer 10 heures à lancer 100 types d'import pour être sûr de tout récupérer. C'est un cas typique où on veut (au moins: je veux) pouvoir naviguer un peu plus librement dans l'arborescence car on se rappelle plus trop quel type de fichiers on a bien pu amasser. À ce moment là, comme l'arborescence a été entièrement construite par plein de logiciels, on se rend compte le bordel avec plein de répertoires aux noms incongrus car automatiquement générés, et on a du mal à retrouver les vrais données.
              J'ai eu le cas encore y a quelques jours pour essayer de retrouver des vidéos dans le smartphone de quelqu'un.

              En tous cas, c'est une idée intéressante et je sais bien que c'est là où on se dirige. Mais c'est assez complexe et y a vraiment plein de choses à prendre en considération avant que tout cela soit fait bien.

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: icones

                Posté par . Évalué à 3.

                on le voit bien sous Android: des photos faites dans un logiciel "caméra" ne sont pas forcément visible dans un autre logiciel "caméra". C'est pénible de devoir naviguer entre les logiciels pour retrouver une photo (je connais des gens qui utilisent plusieurs logiciels de caméra parce qu'ils proposent des filtres différents, etc.).

                Je n'ai pas rencontré ce problème. J'ai 3 logiciels de photos et les images que je reçois par mms. Tout est toujours disponible. Le seul qui m'a posé problème c'est syncthings, mais il s'avère que c'était sur des formats pas pris en charge par le device.

                Pour le reste je suis d'accord.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: icones

        Posté par . Évalué à 0.

        Pas d'icônes est une chose, mais laisser une espace pour les icônes et ne pas en mettre est une autre chose. Je sais que c'est un détail, mais je trouve ça énervant. Pour le reste, Gnome 3.22 est visuellement très réussit.

  • # Video et wayland

    Posté par . Évalué à -4.

    Toutes ces nouveautés font vraiment plaisir a voir !

    il y'a cependant certaines choses qu'on aurait bien aimé voir , pour moi une refonte de Gnome Video manque a l'appel , ce logiciel a besoin d'une refonte totale , en réalité ils n'ont pas beaucoup de travail a faire , ils n'ont qu'a se baser sur l'incroyable MPV et y rajouter une interface GTK+3 optimisé pour Gnome.

    Pour wayland qui pointe le bout de son nez c'est vraiment excellent , sauf que j'ai bien peur que le refus d'Nvidia de mettre a jour leurs drivers legacy pour wayland va géner pas mal d'utilisateurs

    • [^] # Re: Video et wayland

      Posté par (page perso) . Évalué à 3.

      Tu peux très bien installer GNOME MPV. Totem continuera quant à lui d'utiliser GStreamer plutôt que ffmpeg, qui semble mieux respecter / séparer le code qui pose légalement problème, ce qui permet à Fedora / Red Hat (entreprise américaine soumise aux brevets logiciels) de proposer la prise en charge des formats libres par défaut, et de laisser les codecs problématiques (mp3, h264…) en option.

  • # Un "progrès" rigolo de Wayland...

    Posté par (page perso) . Évalué à 7. Dernière modification le 01/10/16 à 19:36.

    Restarting gnome-shell
    Under X11, gnome-shell can be restarted at will without losing the current session (using Alt F2 → "r"). Similarly, the user session under X11 can survive a crash in gnome-shell as the session manager will automatically restart it.
    Under Wayland, being the Wayland compositor as well, gnome-shell cannot be restarted without restarting the entire user session. Using Alt F2 → "r" states that "Restart is not available on Wayland".
    As a result, if gnome-shell crashes under Wayland, the entire user session is terminated unexpectedly.

    https://fedoraproject.org/wiki/Wayland_features#Restarting_gnome-shell

    (je grasse)

    • [^] # Re: Un "progrès" rigolo de Wayland...

      Posté par (page perso) . Évalué à 2.

      Ca pu du string ça…

      • [^] # Re: Un "progrès" rigolo de Wayland...

        Posté par . Évalué à -4.

        C'est wayland quoi… C'est tellement buggue avec tous les compositeurs que j'ai essaye que je ne vois absolument pas comment une distrib un temps soit peu serieuse puisse penser mettre ca par defaut dans 6 mois!

        • [^] # Re: Un "progrès" rigolo de Wayland...

          Posté par (page perso) . Évalué à 7.

          C'est tellement buggue avec tous les compositeurs que j'ai essaye que je ne vois absolument pas comment une distrib un temps soit peu serieuse puisse penser mettre ca par defaut dans 6 mois!

          Sous GNOME cela fonctionne très bien, je teste cela depuis 2 ans maintenant et aujourd'hui c'est largement opérationnel pour les usages standards.
          Le téléphone Jolla sous Sailfish OS tourne très bien avec Wayland également.

          Wayland sera par défaut dans Fedora 25 pour GNOME uniquement, avec possibilité d'utiliser X.org. Il faut bien une distribution pour essayer de faire changer les lignes en rapportant les problèmes en conditions réelles (car des testeurs, il n'y en a pas beaucoup).

          • [^] # Re: Un "progrès" rigolo de Wayland...

            Posté par . Évalué à -1.

            Ben visiblement vu le bug au dessus ca marche en effet tres bien sous gnome-shell et c'est super stable :)

            Jolla c'est mort et enterre et je n'ai pas eu un telephone tel que celui la donc je ne peux pas dire.

            • [^] # Re: Un "progrès" rigolo de Wayland...

              Posté par (page perso) . Évalué à 5.

              Ben visiblement vu le bug au dessus ca marche en effet tres bien sous gnome-shell et c'est super stable :)

              Gnome-shell ne crash pas tous les 4 matins hein, ça crash aussi souvent que X chez moi soit pas bien souvent.

              Le soucis reporté est qu'avant, si le shell merdait, X pouvait relancer GNOME automatiquement, avec Wayland ce n'est pas possible. Ce n'est pas un problème majeur donc.

              Jolla c'est mort et enterre et je n'ai pas eu un telephone tel que celui la donc je ne peux pas dire.

              Jolla n'est pas mort, ça existe encore. Que cela ne soit pas très répandu c'est vrai, mais ce n'est pas la me chose.
              Et pour en avoir un, Wayland ne pose aucun soucis.

          • [^] # Re: Un "progrès" rigolo de Wayland...

            Posté par (page perso) . Évalué à 3.

            Je teste depuis quelques jours GNOME-Wayland 3.22 sous Debian Sid 64 bits, ayant un Intel Core i3-3225 (famille Ivy Bridge) muni d'un HD Graphics 4000 (une puce Gen7) et je me retrouve assez vite avec un système bloqué.
            Je pensais au début que c'était dû à l'usage de Firefox 50 beta 1 qui est en GTK+3 mais j'ai la même chose avec Firefox 49 GTK+2 et aussi sans Firefox, donc le pb n'est pas là.

            Quand j'ai le moniteur système sous les yeux, je vous à un usage anormalement élevé du CPU par moment.
            D'ailleurs j'ai régulièrement des lags avant un freeze complet qui m'oblige à redémarrer ma bécane.
            Pour le moment je ne sais pas trop quel paquet pointer pour rapporter le bogue :/

            Dommage parce que à part la correction de numlock qui n'est pas arrivée dans Debian, tout roule !

            • [^] # Re: Un "progrès" rigolo de Wayland...

              Posté par (page perso) . Évalué à 3. Dernière modification le 05/10/16 à 14:03.

              J'ai eu un problème de copier-coller similaire : parfois, quand je colle depuis le presse-papier, gnome-shell prend 100% de CPU et ne traite quasiment plus les autres événements, ce qui rend la machine inutilisable. J'avais rapporté le bug, mais je n'ai jamais pu l'identifier précisément : tout ce que je sais, c'est que ça arrive en collant (dans une application wayland native comme dans une application X11), mais pas quand je viens immédiatement de copier. Copier quelque chose dans le presse-papier peut faire revenir les choses à un état à peu près normal, mais c'est délicat étant donné que gnome-shell ne répond quasiment plus.

              Edit : depuis, je ne colle que des trucs très récemment copiés, et je ne suis pas retombé sur le problème. Il a peut-être été corrigé.

        • [^] # Re: Un "progrès" rigolo de Wayland...

          Posté par (page perso) . Évalué à 4.

          C'est wayland quoi…

          Wayland (le protocole) n'y est pour rien. C'est l'architecture de mutter/gnome-shell qui est en faute ici. Lit ce commentaire :

          https://bugzilla.redhat.com/show_bug.cgi?id=1367666#c4

          « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

          • [^] # Re: Un "progrès" rigolo de Wayland...

            Posté par . Évalué à 1.

            Tu as oublie la suite:

            C'est tellement buggue avec tous les compositeurs que j'ai essaye

            Tous les compositeurs wayland ont des problemes a un niveau ou l'autre. Donc ce n'est pas wayland ce sont les compositeurs mais bon c'est tout de meme le denominateur commun.

    • [^] # Re: Un "progrès" rigolo de Wayland...

      Posté par (page perso) . Évalué à 1. Dernière modification le 02/10/16 à 20:03.

      Bah, chez moi quand le Shell crashe (ce qui arrive rarement je le concède), Alt+F2 ne répond tout simplement pas, du coup je reboote mon ordi…

  • # numlock

    Posté par (page perso) . Évalué à 3. Dernière modification le 01/10/16 à 22:12.

    Avec cette version, l'état du verrouillage du pavé numérique est censé être sauvegardé lors du redémarrage (https://bugzilla.gnome.org/show_bug.cgi?id=757943), mais ce n'est pas le cas avec ma machine sous Debian.
    Quelqu'un a t-il également ce pb ?

  • # Oxydation

    Posté par . Évalué à 8.

    Ça fait plaisir de voir rust utilisé en dehors de Mozilla!

    Je suis content de voir que la mayonnaise prend vu les promesses faites par ce langage.

    Je me prend même à rêver que le code rust puisse remplacer le C/C++ dans tout le userland.

    Je reste raisonnable puisque je ne parle pas encore du noyau ;)

    Je vais suivre avec attention la suite de l'oxydation _^

    • [^] # Redox

      Posté par (page perso) . Évalué à 2.

      Il y a le projet de réécrire un système d’exploitation libre en Rust : RedOx

      • [^] # Re: Redox

        Posté par . Évalué à 3.

        Oui, c'est un projet hyper ambitieux (trop?). Le problème de tout nouveau kernel est la disponibilité de pilotes pour le matériel.

        Perso, je serais déjà super content rien qu'avec un userland compatible GNU écrit Rust dans une distribution Linux.

        • [^] # Re: Redox

          Posté par (page perso) . Évalué à 5. Dernière modification le 03/10/16 à 10:31.

          il faudrait une passerelle pour utiliser les pilotes linux, un peu comme fait Jolla pour Sailfish OS/Mer avec libhybris cf http://jollafr.org/comment-jolla-profite-de-la-solide-base-android/

          • [^] # Re: Redox

            Posté par . Évalué à 3.

            Merci pour le lien, je vais regarder ça.

            Note que me demande si un telle approche serait approuvée par redoxos vu qu'ils apprécient peu le C.
            Si c'est un micro noyau, peut-être qu'ils peuvent pousser ça dans le user mode?

      • [^] # Re: Redox

        Posté par (page perso) . Évalué à 3.

        Merci pour l'info, je n'avais pas vu passé ce projet. Rust est vraiment le langage qui peut détrôner C/C++ (il serait temps!).

  • # Focus

    Posté par . Évalué à 2.

    Une chose étrange avec gnome shell est le fait qu'aucune fenêtre ne semble prendre le focus. Si ça semble pertinent pour une fenêtre qui apparaît après un traitement long par exemple, c'est aussi le cas pour une fenêtre apparaissant immédiatement ce qui est idiot. Lorsque je clique sur "paramètres" ça me semble normal que la dite fenêtre apparaisse au premier plan

    • [^] # Re: Focus

      Posté par (page perso) . Évalué à 3.

      Tu dois avoir un souci (vieille installation ?) parce qu'en ouvrant les paramètres ou en lançant une nouvelle application, la fenêtre obtient bien le focus de mon côté. Sinon, tu peux toujours te rendre dans l'outil de personnalisation (gnome-tweak-tool), section Fenêtres, puis Mode de focus des fenêtres.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.