Okki a écrit 712 commentaires

Marrant, j'ai trouvé au contraire que c'était particulièrement mal fichu. Il a fallu que je m'y reprenne à plusieurs fois pour réussir à faire de bêtes glisser-déposer, puisque les résultats ne se mettaient pas dans le bon ordre.

Et ne parlons pas des consignes, qui semblent se contredire (glisser-déposer de la gauche vers la droite, notre premier choix devant se retrouver en haut à droite), alors qu'à l'arrivée, les propositions sont déjà à droite, et il semble falloir les déplacer sur la gauche. Et pourquoi nommer les colonnes Vos choix et Votre classement, qui semblent tous deux vouloir dire la même chose. De mettre Proposals aurait été beaucoup moins ambigu.

Il faut également penser à fournir des fichiers Desktop et AppData.

Les applications étant isolées, si elles souhaitent pouvoir accéder au matériel (webcam, microphone…), à la géolocalisation ou autre, l'environnement de bureau fera le lien avec l'utilisateur en lui demandant si oui ou non il souhaite autoriser telle ou telle demande. L'utilisateur doit ensuite pouvoir revenir sur sa décision s'il le souhaite.

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.

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.

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

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

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

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.

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.

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

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

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.

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.

Ce n'est pas non plus la peine de ressasser éternellement de vieilles histoires qui datent de plusieurs années. D'autant plus que la personne en question semble avoir quitté le projet. On peut donc légitimement se poser la question de savoir s'il ne serait finalement pas plutôt préférable de travailler à l'amélioration du mode classique de GNOME (MATE), de développer un dock et un nouveau thème (elementary), d'améliorer le centre de notifications (Budgie)…

De voir autant d'environnements dérivés de GNOME passer leur temps à réinventer la roue, je trouve ça déprimant.

Parce qu'au final, peu importe l'environnement, ça reste finalement plutôt basique en regard de ce que proposent désormais Windows ou macOS. Et pire encore, à sans cesse refaire l'environnement, on en oublie le plus important : les applications. Ce sont elles qui font le succès d'une plateforme. Et là, pour le coup, on a beau entendre à longueur d'année que sous Linux tous les besoins sont couverts, ce n'est clairement pas le cas. Rien que sur des applis de base comme l'agenda ou le client de messagerie, on trouve sous macOS des applications à des années lumière, en termes d'ergonomie et de fonctionnalités, de ce que l'on trouve sous Linux.

Elles pètent réellement, ou c'est juste que personne n'a pensé à incrémenter le numéro de version avec lequel c'est compatible ? Suffit d'éditer un fichier, ou de désactiver la vérification. Franchement, c'est plutôt rare quand ça casse vraiment.

Il y a tout d'abord eu un article de calimaq, Pepper et Carrot : une bande dessinée Open Source publiée chez Glénat, où Béhé et Boulet sont venus se plaindre que c'était du grand n'importe quoi, que David Revoy se faisait grave exploiter par ces pourris de Glénat, puis que le libre c'était mal, que ça allait tuer l'industrie de la BD…

Plusieurs blogueurs ont ensuite écrit sur le sujet, à commencer par Luc Didry avec L'art et le libre, suivi par Neil Jomunsi avec Message aux artistes : sortez-vous les doigts du c**, qui contient d'ailleurs une longue réponse de David Revoy.

C'est la même chose pour les tuiles, qui ne sont que des données mises en forme. Et comme les données sont également trop grosses et rapidement périssables, ils interrogent le service plutôt que de les fournir avec l'application.

Le souci, c'est que ta remarque vaut aussi pour les données géographiques, puisque ils dépendent d'OpenStreetMap, ou de la possibilité de définir des itinéraires, puisque ils dépendent de GraphHopper. Puis ça doit également être récursif, puisque pour certains points d'intérêt, OpenStreetMap et Wikipédia tirent parti l'un de l'autre, il me semble.

En même temps, si OSM avait dès le départ autorisé les projets libres à réutiliser ses tuiles, on en serait pas là. D'autant plus que Cartes permet également d'éditer, et apporte donc de potentiels nouveaux contributeurs au projet.

Plusieurs fois j'ai été tenté de contribuer à ton projet (mon amoureuse étant elle-même une petite marmotte, je trouvais ça normal :p), mais bien que je comprenne tout à fait que pour la visibilité à long terme pour préfériez des paiement mensuels réguliers, je ne suis pas particulièrement fan.

N'y a t-il pas un bête Paypal pour donner une seule fois une somme un peu plus conséquente ? (j'aime bien varier les projets tous les mois, selon mes envies et mes moyens du moment).

On pourrait formuler ça autrement. Canonical a encore développé un truc tout seul dans son coin rien que pour Ubuntu, quand d'autres ont préféré créer un projet Freedesktop distribution agnostique. C'est la même chose pour Mir vis-à-vis de Wayland, et tout comme ils ont finit par abandonner upstart au profit de systemd ou le Software Center au profit de GNOME Software, je te paris qu'un jour il en sera de même de Mir et Snap.

Je n'ai touché ni à l'un, ni à l'autre, mais vu de loin, j'ai l'impression que c'est justement l'une des grosses différences avec Flatpak. Là où Snap semble absolument tout inclure, Flatpak fait appel à des runtimes. On a par exemple les runtimes Freedesktop, GNOME, KDE… Et il peut y avoir différentes versions d'un même runtime (GNOME 3.18, 3.20)

À l'arrivée, s'il y a des failles dans X11, Wayland, Mesa, DBus, SDL… c'est le runtime Freedesktop qui sera mis à jour, et non pas le Flatpak de l'application.

Alors, bien évidemment, le conteneur pourra également contenir certaines bibliothèques bien spécifiques, mais ça représente tout de même beaucoup moins de risques vis-à-vis d'éventuelles mises à jour incessantes du conteneur. Autre avantage, ça devrait également occuper bien moins de place. À première vue, 200 Mo pour le Snap, contre 14 Mo pour le package Ubuntu. Reste à créer un Flatpak pour pouvoir comparer XD

Maintenant, je ne sais pas vous, mais je trouve ce fichier .yaml super vilain (rien que la palanquée d'export, ça me refroidit). Pour le coup, un survol de la doc de Flatpak me donne l'impression de quelque chose de bien plus propre et mieux pensé.

Sinon, pour rester dans la sécurité, côté Snap ils parlent bien de sandboxing, mais je n'ai rien trouvé dans leur doc vis-à-vis des autorisations. Côté Flatpak, par défaut il n'y a aucun accès aux fichiers, réseau, périphériques, process en dehors de la sandbox, services (X, D-Bus, PulseAudio…). Et pour pouvoir y accéder, il faut le spécifier dans la conf du conteneur. Ensuite, de ce que j'ai compris, il y aura des demandes utilisateur au niveau de l'environnement de bureau. « L'application Tartampion souhaite pouvoir accéder à la webcam. Souhaitez-vous l'autoriser ? ».

Le site Flatpak étant nettement plus complet et mieux foutu que les quelques pages que j'ai pu trouver sur developer.ubuntu.com, ça me donne tout de même l'impression que l'ensemble du projet Flatpak a réellement été mieux pensé. Maintenant, j'ai sans doute raté quelque chose (ça serait tout de même étonnant que ça n'ait pas été pris en compte), et serais donc curieux de connaître l'avis des primo adoptants.

Snap c'est uniquement Ubuntu, quand Flatpak tournera partout (y compris sous Ubuntu). Par contre, bien que la technologie soit déjà prête, toutes les logithèques ne le prennent pas encore en charge (ce qui oblige à passer par la ligne de commande). Dans le cas de GNOME Software / Ubuntu Software, il faudra attendre la prochaine version, prévue pour le mois de septembre.

Je me suis fait la remarque après coup, mais la flemme d'éditer :p

Maintenant, il est évident que les distributions continueront à packager au format DEB, RPM ou autre de leur côté. Par contre, au niveau de la distribution de binaires sur les sites web officiels des différents projets, j'espère qu'un unique format sortira vainqueur. Je trouve idiot et contre-productif que sur un format censé unifier les différentes distributions et régler le problème de la fragmentation, on en arrive encore à sortir cinquante nouveaux formats différents (AppImage, Flatpak, Snap, Guix ?)

Parce qu'il est évident que chaque projet ne va pas s'amuser à packager dans cinquante formats, et si c'était le cas, les utilisateurs en seraient encore à se demander ce qu'ils doivent récupérer, là où tout « paraît » plus simple avec un unique .exe sous Windows…