Okki a écrit 712 commentaires

Si tu fais référence à Folder Color, ça fonctionne aussi bien avec Nautilus que Nemo ou Caja.

Me souviens plus si c'était ce message exactement, mais on va dire que ça fait l'affaire ;-)

« Your concern is about using fast forward merge. Yes, we raised this concern as the top most important for us, and as we mention in the wiki we have good news, GitLab team is willing to strongly consider making fast forward merge to CE if GNOME decides to switch to GitLab. »

J'ai lu que si GNOME choisissait finalement Gitlab, ces derniers accepteraient de passer certaines fonctionnalités dont le projet aurait besoin dans la version communautaire.

Les lecteurs libres que j'ai testé ne prennent pas non plus en charge les modèles 3D, que l'on peut normalement faire pivoter, cacher certaines pièces…

Ah oui, puis un autre point qui n'a pas été abordé, ce sont les créatifs. De nos jours, ça peut tout aussi bien être des professionnels particulièrement compétents qui maîtrisent leur sujet, comme ça peut être de simples YouTubeurs passionnés. Avec un Mac et quelques logiciels grand public, ils peuvent créer des vidéos, faire du montage, ajouter quelques effets spéciaux… puis publier leur création sur YouTube.

Au niveau de l'audio, on retrouve d'ailleurs pas mal de YouTubeurs qui se sont fait connaître par leurs reprises de titres à succès.

Ça n'a pas été abordé dans ces 3-4 lignes de blog, mais ça se trouve, personne n'a jamais eu l'intention de remettre en cause JACK, qui restera la solution privilégiée par les pros, et que PipeWire tentera juste de répondre aux mêmes problématiques, tout en étant orienté grand public.

Ce ne sont que des théories, mais encore une fois, sans site et sans articles complets sur le sujet, on ne peut que supputer :p

Par contre, je te rejoins complètement sur les applications. Ce qui fera le succès d'une plateforme, quelle quelle soit, ça sera toujours ses applications. Maintenant, pour concevoir de bonnes applications, il faut également pouvoir proposer de bonnes bases et de bonnes technologies.

J'ai surtout l'impression que tu t'excite un peu pour pas grand chose. Ou du moins, que tu le fais prématurément. Pour le moment, il n'y a encore aucun site officiel, le développeur ne s'est pas exprimé sur le sujet, je n'ai pas vu passer d'article explicatif complet…

En gros, pour le moment, nous n'avons droit qu'à quelques lignes d'un développeur externe au projet, qui semble juste parler de son existence, sans rentrer dans les détails. À aucun moment il ne parle de remplacer Jack. Ni même PulseAudio, d'ailleurs. Au contraire, il indique que les utilisateurs ne voudraient pas subir à nouveau tous les problèmes qu'ils avaient rencontrés à l'époque de la migration vers PulseAudio. Les applications devront donc être compatibles sans la moindre modification.

Ensuite, de ce que je comprends de la référence à JACK, ça semble juste vouloir dire que ça devra répondre correctement aux problématiques auxquelles répondent JACK et PulseAudio. J'extrapole, mais j'imagine que les applications JACK resteront des applications JACK et que PipeWire fera en sorte d'être complètement transparent, sans rajouter de la latence, par exemple.

Et pour finir sur l'histoire du citoyen de première classe, connaissant Christian Schaller et Fedora, à mon avis, ça veut juste dire que les créatifs qui opteront pour Fedora (ne pas oublier que tout le monde n'est pas ingé son) auront droit à un système le plus simple possible, où les différents projets s'emboîteront parfaitement et où tout fonctionnera out of the box.

Je ne fais pas de MAO, mais quand je jette un oeil à la page décrivant GNU/Linux sur le site de Linux MAO et que je lis dans les inconvénients la « Difficulté de configuration de certaines distributions et obligation de parfois mettre "les mains dans le cambouis" », ça donne vachement envie. J'imagine que c'est cette image qu'ils souhaitent changer.

J'ai l'impression que leur vision de la stabilité diffère de celle des utilisateurs. Je peux me tromper, mais je vois plus une recherche de la stabilité dans le sens où une application qui ne proviendrait pas forcément de leurs dépôts (du style, une application propriétaire) aurait la garantie de pouvoir fonctionner à l'identique du début à la fin, sans surprise.

À l'inverse d'utilisateurs qui aimeraient bien voir corriger des bugs (qu'on trouvera toujours, y compris chez Debian) pour obtenir un système toujours plus stable. La logique voudrait que si un développeur sort 36 versions correctives de son application ou de sa bibliothèque, sans ajouter de nouvelles fonctionnalités, elles soient toujours intégrées dans Debian. Mais ça ne semble pas être le cas, puisque j'imagine qu'ils ont trop peur qu'un correctif puisse avoir des effets de bords inattendus, qui iraient à l'encontre de leur vision de la stabilité.

Donc pour moi, non, une Debian stable n'est pas stable. Y compris sur un serveur, puisque sur le miens, j'ai déjà rencontré un certain nombre de problèmes (allant jusqu'aux plantages) avec lftp, screen, rtorrent… Problèmes qui avaient été corrigés dans les versions plus récentes fournies par Ubuntu Server.

Dans certains domaines qui peuvent partager cette vision de la stabilité, Debian est sans doute effectivement le meilleur choix possible. Mais je ne pense pas qu'il faille dire aux particuliers qu'avec une Debian ils auront un système bien plus stable et plus fiable qu'avec d'autres distributions.

Ça fait tout de même un certain nombre d'années que les machines sont commercialisées avec des systèmes 64 bits. À tel point que la plupart des éditeurs de systèmes d'exploitation annoncent abandonner prochainement les éditions 32 bits. Côté Linux, Arch et Fedora l'ont déjà annoncé ; et il y a quelques jours, j'apprenais qu'il en serait bientôt de même pour macOS.

Ensuite, quand t'as un système d'exploitation 64 bits, autant n'utiliser que des applications 64 bits (y compris un bête ls dans un terminal), sinon il faut s'emmerder avec d'innombrables bibliothèques de compatibilité 32 bits, ce qui fait bêtement perdre de l'espace, aussi bien sur le disque qu'en mémoire, puisque certaines bibliothèques seront chargées dans leurs versions 32 et 64 bits.

Donc, à moins de continuer d'utiliser un système qui n'est sans doute plus supporté, genre un vieux Windows XP 32 bits et son lot de virus et autres merdes - d'ailleurs, pour rappel, même si Microsoft a récemment comblé une ou deux failles béantes particulièrement dangereuses, ça ne signifie pas qu'ils vont s'occuper de toutes les autres failles laissées grandes ouvertes, ou qu'ils réagiront encore à l'avenir - à moins que ce soit par obligation, je ne vois pas trop quel intérêt il peut y avoir à continuer d'utiliser des applications 32 bits à notre époque.

À mon avis, c'est juste le portage GTK+ 3 qui apporte de facto la compatibilité Wayland.

En ce qui concerne Flatpak, c'est Linphone qui a un peu merdé en balançant des lignes de commandes, puisque si ta distribution et ton environnement de bureau le prennent correctement en charge, ils pourraient très bien proposer un .flatpakref en téléchargement, comme ils le font déjà pour les .exe Windows ou les .dmg macOS. Ça ouvrirait la logithèque et l'utilisateur n'aurait plus qu'à cliquer sur Installer. Une fois fait, comme pour n'importe quelle autre application, elle apparaît bien parmi celles installées et il suffit de taper son nom ou de cliquer sur son icône pour la lancer.

La réalité, c'est plutôt que le projet manque cruellement de main d’œuvre. Si on prend l'exemple de Georges Stavracas, le développeur initial d'Agenda, il travail également sur GNOME To Do et en ce moment il refait le tiling de Mutter pour pouvoir mettre quatre fenêtres côte-à-côte et pouvoir les redimensionner.

Si Mutter avait eu plus de développeurs, il aurait pu se concentrer sur l'agenda, au lieu de devoir passer d'un projet à l'autre pour combler les manques ou corriger les bugs qui lui posent problème.

Et la plupart du temps, c'est juste ça. Faut pas chercher plus loin et partir dans des théories comme quoi ça serait un projet autoritaire qui refuserait toujours tout. C'est juste un manque de main d’œuvre et de temps pour les bénévoles qui bossent dessus.

Manque de main d’œuvre d'autant plus criant qu'il aura fallu attendre un Google Summer of Code pour qu'un étudiant se mette à implémenter les événements récurrents dans l'agenda.

C'est bien dommage qu'il n'y ait pas une équipe de développeurs payés à plein temps pour s'occuper des applications de base. Parce que les dons à la fondation, ça sert juste à payer les frais pour envoyer quelques développeurs lors d'événements comment le GUADEC ou GNOME.Asia, organiser un ou deux hackathons… C'est nécessaire et c'est très bien, mais ça ne remplacera jamais toute une équipe payée à plein temps, à mon avis.

Faudrait voir ce qu'il te manque exactement.

Jeremy Bicha, de l'équipe desktop d'Ubuntu, a repris la maintenance de l'Outil de personnalisation. Avec d'autres développeurs, ils ont déjà ajouté la possibilité de désactiver le pavé tactile lors de la saisie, celle d’afficher le niveau de charge de la batterie dans la barre supérieure ou de pouvoir choisir l’emplacement des boutons de la barre de titre. Cette possibilité existait déjà, mais il fallait autrefois passer par l'éditeur dconf. À n'en pas douter, d'ici septembre, ils ajouteront sans doute de nouvelles possibilités de configuration.

À côté de ça, avec un peu de chance, on aura peut être droit au tout nouveau Centre de contrôle. Ça fait déjà quelques temps que les développeurs travaillent à sa refonte, ce qui devrait faciliter l'ajout de nouvelles options, ainsi que sa maintenance (ce qui signifie plus de temps consacrable à d'autres tâches).

Personnellement, je vois plutôt GNOME comme une feuille vierge que l'on peut personnaliser à l'envie. À l'aide d'extensions, on peut par exemple ajouter un dock à la macOS, un panel à la Windows, un menu principal plus traditionnel… Il existe même des scripts, tels que GNOME Layout Manager, pour radicalement changer l'expérience utilisateur d'un simple clique.

Puis maintenant qu'Ubuntu revient vers GNOME, je pense que le projet est prêt à faire quelques efforts et accepter d'ajouter quelques options, voir quelques clés dconf supplémentaires, histoire de rendre l'environnement un peu plus personnalisable par les utilisateurs et les distributions.

Pour Chrome, c'est en train d'arriver.

Tu peux toujours jeter un œil à ce que propose la concurrence (Fantastical, Informant…) pour voir qu'il reste encore du boulot : ajout d'événements en langage naturel, gestion des fuseaux horaires, pouvoir trouver facilement des disponibilités communes entre collègues, intégration avec Cartes (il y a pourtant une case emplacement, mais ça ne me propose aucune carte pour autant)… sans parler des fonctionnalités de base, comme les événements récurrents ou le simple fait de pouvoir imprimer (ou alors, c'est bien planqué).

Pour moi, le gros souci, c'est que certaines entreprises comme Red Hat vont employer un certain nombre de développeurs sur des technologies bas niveau ou certaines applications importantes pour eux (gestionnaire de fichiers, logithèque), tout en délaissant la majeure partie des applications utilisateur, qui manquent cruellement de main d’œuvre.

Contacts a l'air a l'abandon depuis un certain temps et il aura fallu plusieurs années à quelques bénévoles pour qu'Agenda dispose enfin des trois vues attendues (la vue en semaine n'étant arrivée qu'avec GNOME 3.24). Avec un peu de chance, pour la version 3.26 on aura peut être droit à la prise en charge des événements récurrents, un éventuel panel, une possible intégration à Contacts pour inviter des gens à un événement… mais encore faut il des gens motivés (ou qui ont le temps libre nécessaire) pour implémenter tout ça.

Il fait peut être référence au tiroir de messagerie qui est, à mon sens, tout sauf intuitif. Pour remettre les icônes sur la barre supérieure, il existe bien l'extension TopIcons Plus, mais ça ne correspond donc pas à l'expérience proposée par défaut.

Et il oublie le principal. Ubuntu proposait Unity, mais également les applications GNOME. Changer de shell n'impose pas aux utilisateurs de réapprendre le fonctionnement des différentes applications. Ça ne modifie pas non plus leurs préférences utilisateur. S'ils avaient configuré des services en ligne (Google, Nextcloud…) ils pourront continuer de les utiliser. Il n'y a rien à convertir ou adapter (préférences, historique, formats de fichiers…).

On reste dans la continuité. Pour un usage pro, j'imagine que c'était la meilleure solution.

Ce qui ne m'empêche pas d'envier KDE Connect. J'espère qu'un jour on aura droit à un équivalent bien intégré pour les environnements utilisant la stack GNOME.

Sous Debian, il me semble que le nombre de paquets est complètement faussé par le fait qu'ils séparent tout (fichiers de développement, symboles de débogage, documentation…). Sous Arch, en général il n'y a qu'un paquet, qui prend peut être un peu plus d'espace disque, mais où l'on s'emmerde moins à chercher quoi installer. Je rajouterai donc ça dans les avantages :p

Je viens de tester à l'instant, et de mon côté, le clavier visuel (activé depuis le Centre de contrôle puis Accès universel) fonctionne bien dans les différentes applications GNOME nécessitant de la saisie de texte : Gedit, GNOME Terminal, Nautilus, Geary, Agenda… Ça semble également fonctionner avec HexChat, qui est toujours en GTK+ 2, ou LibreOffice.

Par contre, le placement n'est pas toujours malin. Par exemple, avec HexChat, j'ai la boîte de saisie au bas de l'écran, qui est donc recouverte par le clavier visuel qui apparaît au même endroit.

Et sinon, je suis plutôt limité en applications Qt, mais ça ne semble pas fonctionner avec VirtualBox.

Sérieux vous allez prendre le nom Gourmet pour gnome-recipes ?

Au temps pour moi. Me suis planté. Je ne sais pas pourquoi, j'étais persuadé d'avoir vu ce choix passer, mais semblerai que personne ne se soit encore penché sur la traduction de l'application et qu'un nom reste donc à choisir. Ça ne m'étonnerai pas qu'on se retrouve avec un Recettes à l'arrivée.

Gourmet (le nom français) a été pensé dès le départ comme une application Flatpak, dans le but de voir plus facilement tout ce qui aurait besoin d'être amélioré de ce côté là.

Et puisque t'es sous Xfce, j'imagine qu'ils n'ont pas encore implémenté les portails comme sous GNOME. C'est ce qui permet de demander à l'utilisateur s'il souhaite autoriser l'accès à certains périphériques, à son dossier personnel, à sa géolocalisation… Et de pouvoir ensuite révoquer ces autorisations à tout moment.

Sinon, certaines de tes remarques sont bien prévues pour la prochaine version, comme l'import / export dans d'autres formats, l'ajout ou l'édition plus simple des ingrédients, un meilleur partage, comme de pouvoir envoyer sa liste de courses sur son téléphone…

Ça a pourtant vachement avancé côté simplicité de contribution. J'ai récemment écrit un billet de blog (basé sur celui de Carlos Soriano), où l'on apprend qu'à l'aide de Builder et de Flatpak, on peut désormais contribuer rapidement à une application GNOME (mais pas que, de ce que j'ai compris, n'importe quel autre environnement qui se mettrait à utiliser Flatpak pourrait faire de même).

D'après un article de The Register (en français chez Next INpact), de potentiels futurs investisseurs auraient demandé un audit externe, qui en est arrivé à la conclusion qu'un desktop libre ça rapportait que dalle et qu'il valait mieux se recentrer sur ce qui rapporte, à savoir les trucs à la mode comme le cloud et l'Internet des objets. Au final, il y aurait déjà 80 licenciements de sûrs, et peut-être d'autres à venir.

Ce n'est qu'un avis personnel, mais je ne pense pas que Canonical soit en difficulté (n'étant pas côté en bourse, il me semble qu'ils n'ont jamais publié le moindre rapport financier). Par contre, ils devaient effectivement perdre de l'argent sur l'activité poste de travail, et préfèrent donc grandement réduire la voilure. De ce que j'ai compris, il n'y aura plus qu'une équipe minimum. Il n'y que les départements conseil et support qui n'ont pas l'air d'avoir été touchés.

T'as des exemples concrets ? La documentation Flatpak ne donne pas l'impression que ce soit particulièrement compliqué (même si je reconnais n'avoir créé ni l'un ni l'autre). Je la trouve même bien plus clair, moins fouillis et moins éparpillée que celle de Snaps, qui renvoi par exemple vers des billets de blog pour certaines parties, comme la création d'interfaces.