Journal La fin de la vue en arborescence dans Nautilus ?

Posté par (page perso) . Licence CC by-sa
29
31
juil.
2012

Arg. Moi, ardent défenseur de gnome, parfois jusqu'à l'encontre de la raison, voilà qu'il va falloir reconnaitre un "petit" souci à venir…

Alors qu'un développeur Gtk, Benjamin Otte se plaint de la direction actuelle

et qu'ici même on redoute que Gnome n'en ait plus que pour le tactile

, voici que la vue en arborescence (et bien d'autres fonctions) quitteraient Nautilus , suscitant bien des remontrances

Par exemple, les signets ne seraient plus disponibles dans le menu, et donc forceraient l'utilisation du panneau latéral par défaut (montrant entre autres ces favoris), ce qui déjà en soi casse bien des choses.

Aïe. Heureusement que Linux offre des dizaines de gestionnaires de fichiers!

l'un des commit en question

  • # A fond

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

    Ils me semblaient avoir lu dans un commentaire sur linuxfr que l'objectif était surtout d'éliminer Nautilus ; le raisonnement part du constat qu'après tout, dans un monde de fichiers indexés, pourquoi aurait-on besoin d'un explorateur de fichier alors qu'un moteur de recherche suffit pour 99% des cas d'utilisation (= chercher un fichier) ?

    • [^] # Re: A fond

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

      J'ai beau être séduit par les évolutions promises de gnome journal , et d'autre part par l'intégration de tracker (ex dans "documents"). Mais vouloir supprimer Nautilus, n'est-ce pas un peu orgueilleux pour l'instant? ( tout simplement : un peu tôt?)

      Si vraiment le relai fait mieux le boulot, les anciennes applis ne seront plus utilisées - inutile d'y toucher dans ce cas

      • [^] # Re: A fond

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

        Prenons les choses dans l'autre sens. Si on attend qu'un logiciel soit parfait pour commencer le boulot sur un autre logiciel qui en dépend, la super feature que tu attends sera dépassée le jour où tu l'auras entre les mains. Le seul moyen c'est donc de paralléliser, et corriger au fur et à mesure la direction. C'est de l'itératif, de l'approche et erreur, comme à peu près tout dans la vie puisque l'être humain fonctionne comme ça.

        On peut tout à fait vivre sans panneau latéral avec une arborescence, même si je comprends la douleur de ceux qui l'avaient complètement intégré à leur workflow. Je me suis néanmoins toujours demandé comment on pouvait être efficace avec ce truc là, les gens passant 3 plombes à retrouver le dossier dans lequel faire le "copier", puis 3 autres plombes pour le "coller".

    • [^] # Re: A fond

      Posté par . Évalué à 10.

      le raisonnement part du constat qu'après tout, dans un monde de fichiers indexés, pourquoi aurait-on besoin d'un explorateur de fichier alors qu'un moteur de recherche suffit pour 99% des cas d'utilisation (= chercher un fichier) ?

      Il suffit juste de ne pas avoir plusieurs fichiers portant le même nom dans la zone de recherche. Mais bon qui serait assez bête pour donner exactement le même nom à plusieurs fichiers différents ?

      Bon je vous laisse, j'ai mon main.c qui compile plus quand je fais un make, faut que je regarde si le problème ne vient pas de configure…

      • [^] # Re: A fond

        Posté par . Évalué à 2.

        C'est un peu le même problème que la suppression du menu d'une application par le "Head-Up Display" sous unity. Et la raison était bien expliquée.

      • [^] # Re: A fond

        Posté par . Évalué à 1.

        Mais bon qui serait assez bête pour donner exactement le même nom à plusieurs fichiers différents ?

        Comment on fait pour avoir un fichier avec le même nom absolu sous Unix ?

        Je suppose que l'indexation repose sur les noms absolus des fichiers non ?

        Donc dans ton moteur de recherche de fichiers tu peux taper par exemple vmcoincoin/main.c ou zino/main.c ?

        Les répertoires étant aussi des fichiers, je me demande ce que taper juste le nom d'un répertoire (en considérant qu'il n'y a aucun véritable fichier avec le même nom) devrait provoquer comme comportement… Ah bah si en fait, ouvrir un truc qui ressemble à une liste de fichiers :)

        J'ai rien compris ? (pas sur la tête ! /o\)

        Oui j'ai eu une dure journée…

        • [^] # Re: A fond

          Posté par . Évalué à 6.

          Donc dans ton moteur de recherche de fichiers tu peux taper par exemple vmcoincoin/main.c ou zino/main.c ?

          Effectivement, quand tu sais déjà ou le fichier se trouve tu peux rentrer suffisament d'informations pour permettre au système de recherche de le trouver très rapidement.

          • [^] # Re: A fond

            Posté par . Évalué à 9.

            Quand tu sais où est le fichier tu n'as pas à le chercher !

            • [^] # Re: A fond

              Posté par . Évalué à 10.

              Quand tu sais où est le fichier tu n'as pas à le chercher !

              C'est bien une réaction de power user ça…

            • [^] # Re: A fond

              Posté par . Évalué à 1. Dernière modification le 31/07/12 à 20:22.

              Non tu ne sais pas où est ton fichier, tu ne sais pas qu'il se trouve dans /home/bob/dev/src/tribune/uncoincoin/vwmcoincoin

              Tu sais juste que tu veux le main.c de ton projet de coincoin…

              Après si on a aussi un /home/bob/dev_test/src/tribune/uncoincoin/vwmcoincoin/main.c

              Le moteur va sortir une liste de fichiers d'enregistrements correspondant à la requête coincoin main.c

              Ce n'est pas forcément déconnant, on peut même imaginer coupler ça avec un système de tag sur les fichiers. Mais là c'est plus le même OS !

              Perso si on en arrive là, à ne plus pouvoir accéder à ses fichiers sous forme d'arborescence, même via le shell, je passe à FreeBSD sans hésiter…

              • [^] # Re: A fond

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

                locate main.c | grep coin | grep home
                
                

                non ?

                • [^] # Re: A fond

                  Posté par . Évalué à 3.

                  Oui mais c'est goret. En plus ça implique de lancer updatedb régulièrement, si on a un système où les fichiers changent vite ça n'a plus aucun intérêt :)

                  • [^] # Re: A fond

                    Posté par . Évalué à 2.

                    goret d'un point de vue de lennart certainement
                    (un seul gros truc bien binaires largement sous documenté qui veut tout faire, mal, sans possibilité aisée de changé les différentes parties).

                    Mais arrête moi si je me trompe : la on parlais d'arrêter d'utiliser un système hierarchique pour stocker/accéder au fichier parce que maintenant on a une super fonction "recherche".

                    Tu nous indique donc que le locate est "goret" car il doit lancer un updatedb régulièrement.

                    Mais rassure moi, ton système de recherche de fichier top moumoute, il se base bien sur un index? Il ne fait quand même pas un find à chaque fois, si ?

                    enfin, bientot on aura le nom des fichiers du voisin et lorsque qu'on cherchera "main" on trouvera "main_porno" de l'utilisateur a coté \o/ (et bonne chance au sysadmin pour modifier facilement les backend d'indexation intégré à gnome et consors).

              • [^] # Re: A fond

                Posté par . Évalué à 10.

                Perso si on en arrive là, à ne plus pouvoir accéder à ses fichiers sous forme d'arborescence, même via le shell, je passe à FreeBSD sans hésiter…

                Ça commence à devenir pathétique les gens qui agitent sans arrêt le spectre BSD (quand en plus c'est pour une raison aussi fumeuse ça en deviens tordant). Si vous voulais passez à BSD faites-le, ça ne dérange personne. BSD c'est pas méchant, ça mord pas, ça vous tend les bras. Arrêtez de dire que vous allez le faire parce que vous êtes de mauvais poil.

                C'est tout de même dommage de réagir ainsi *BSD, les BSD ont leurs propres qualités autre que « ça ressemble à Linux d'avant, ça me rassure ».

                Pour ton cas particulier c'est bidon parce que le Gnome que tu va retrouver sur *BSD sera soit « vieux » (= ce ne sera pas le dernier), soit il aura le même problème que sous linux.

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

                • [^] # Re: A fond

                  Posté par . Évalué à 4.

                  C'est vrai j'étais partis loin.

                  ne plus pouvoir accéder à ses fichiers sous forme d'arborescence, même via le shell

                  Oui je fais des cauchemars des fois :)

                  Et là j'ai une insomnie donc je vais raconter ma vie.

                  Je me souviendrai toujours d'une phrase que l'on ma sortie alors que je n'étais qu'un jeune n00b sur IRC, qui vient à peine d'être délivré d'un Windows 98 par une Mandrake "copie d'amis" d'une version boîte complète, son premier ordinateur à lui, avec un modem RTC pas patché…

                  Ouai c'est bien tu es passé à Linux, tu finiras par passer à FreeBSD.

                  J'ai déjà essayé FreeBSD, sur un "serveur", une vieux laptop que j'avais sauvé de la benne, là où je travaillais on payait le fabricant, que je ne citerai pas, pour "récupérer" le matos soit disant obsolète, je te laisse imaginer ce qui pour je pense des raisons comptables s'entassait dans la cave… J'ai aussi testé PC-BSD deux trois fois dans des VM pour voir.

                  J'ai notamment apprécier le principe des ports, au lieu de distribuer un package de source patché, on distribue un ensemble de patch et un simple lien vers la version upstream auquel il s'applique. Ceci venant bien sûr en plus d'un système de package binaire pour la base du système.

                  C'est propre et c'est, à mon avis, une vision différente de ce que représente l'upstream dans la conception d'un OS complet.

                  Je continue à préférer Debian, d'une part parce que "l'OS universel" ça pète, d'autre part parce que c'est l'OS que j'ai choisis d'apprendre à plein temps fût celui là.

                  Coucou à toi qui à lu jusque là.

                  • [^] # Re: A fond

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

                    Depuis le temps, tu aurais sans doute pu apprendre que distribuer le tarbal + des patches, c'est ce que font deb et rpm. Dans le .deb, tu as le fichier original et un aggregat de patch ( sous forme d'un gros patch en pratique, qui se divise en plusieurs patches ). Sous rpm, tu as une archive src.rpm qui contient les sources, et les patches.

                  • [^] # Re: A fond

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

                    ok pour le système des ports, qui est bien fait (assez proche d'une gentoo), mais par contre le système de packages binaires est une catastrophe : jamais à jour, avec des dépendances cassées.

    • [^] # Re: A fond

      Posté par . Évalué à 10. Dernière modification le 31/07/12 à 18:46.

      le raisonnement part du constat qu'après tout, dans un monde de fichiers indexés, pourquoi aurait-on besoin d'un explorateur de fichier alors qu'un moteur de recherche suffit pour 99% des cas d'utilisation (= chercher un fichier) ?

      Euh, chercher un fichier pour l'ouvrir, pourquoi pas.

      Après pour le copier d'un point A à un point B, pour en changer les droits, pour simplement savoir ce qui se trouve sur une clé USB, ou encore faire un tri par taille ou par date, ça serait pas la joie.

      Bon, ok, vous et moi on est peut être plus portés sur la ligne de commande dans tous ces cas, mais si l'objectif de Gnome est bien comme on le dit de toucher un large public, ça le ferait moyen…

      *Sano*

      • [^] # Re: A fond

        Posté par . Évalué à 10.

        Mais non, tu ne comprends rien: l'avenir de Gnome OS, c'est les fichiers classés par index au lieu de répertoire.

        On va donc supprimer les répertoires. De toute façon c'était beaucoup trop compliqué pour l'utilisateur!

        ----------->[ ]

        • [^] # Re: A fond

          Posté par . Évalué à 6.

          Et on finira par regrouper les fichiers en bibliothèques, euh wait…

          Gnome abandonne pas le desktop en fait, il abandonne Unix !

        • [^] # Re: A fond

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

          Tu rigoles, mais sur Android (ou autre) avec le protocole MTP, on n'en est pas loin.

          blog.rom1v.com

      • [^] # Re: A fond

        Posté par . Évalué à 3.

        Après pour le copier d'un point A à un point B, pour en changer les droits, pour simplement savoir ce qui se trouve sur une clé USB, ou encore faire un tri par taille ou par date, ça serait pas la joie.

        Attends, l'idée c'est de transformer Gnome en iPhone. Tu rajoutes une couche de DRM, et hop ! Tu ne pourras copier que les fichiers que tu auras crées sur ton terminal. Tu rajoutes une couche de GnomeStore et hop ! Tu ne pourras plus que consommer des fichiers verrouillés. Et là Gnome peut supprimer le copier/coller mais déguiser ça en ajout de fonctionnalité : en appelant l'ersatz "GnomeSync".

      • [^] # Re: A fond

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

        Quand ton seul outil est un marteau, tous les problèmes ressemblent à un clou. Le but c'est donc d'avoir des outils adaptés à chaque tâche. C'est pour cela que la recherche est rendue globale et poussée vers le shell, où tu pourras chercher tes fichiers, tes contacts, tes programmes.

        Regarde comment se présente la boîte de téléchargement de Firefox, tu peux faire un clic droit et demander à ouvrir le dossier contenant ce fichier. J'imagine que c'est un peu vers ça que tend GNOME, et ton fichier sera visible dans Nautilus ou dans Documents.

    • [^] # Re: A fond

      Posté par . Évalué à 10.

      Je vois bien les utilisateurs chercher "DSCN_4242.jpg"…

      • [^] # Re: A fond

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

        Les utilisateurs, ils s'en fichent totalement du nom du fichier.

        Ils ont une application de galerie photos qui s'occupe de tout, et efficacement.

        Envoyé depuis mon lapin.

        • [^] # Re: A fond

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

          Et ils pleurent sans arrêt "sainul linux il m'a perdu mes photos".

          http://devnewton.bci.im

          • [^] # Re: A fond

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

            Je suis très content de la gestion des photos sur Android, et il ne m'a jamais rien perdu.

            Envoyé depuis mon lapin.

    • [^] # Re: A fond

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

      Pour utiliser un OS avec un système de fichiers indexé depuis maintenant quelques années (2005, je crois), je suis convaincu qu'un vrai explorateur de fichiers est nécessaire.

      L'indexation est pratique car elle permet de chercher dans pas mal de sources de données (fichiers, mais aussi mails, calendriers, contacts, historique internet, …) pour trouver un objet unique. Exemples : retrouver le PDF d'un livre à partir de quelques mots-clefs du livre, un rdv dans ton agenda en te souvenant d'une personne invitée… Ça marche bien aussi en lanceur d'applications.

      Par contre, à part ce cas (trouver un objet unique), l'indexation est franchement peu pratique :
      - soit parce que le fichier n'est pas unique (des copies à peine modifiées existent)
      - soit parce que tu veux travailler avec un ensemble de fichiers (un lot de photos avec du texte, les fichiers source d'un programme, …)
      - l'indexation ne t'offre pas de garantie sur le résultat de ta recherche : tu archives de façon automatique tous les fichiers d'un projet pour le sauvegarder. Pour ça, tu choisis comme critère de recherche « extension:".pdf", contient: "TOTO" ». Manque de pot, tu télécharges un autre PDF qui n'a rien à voir, mais qui contient également TOTO. Pouf, tu vas l'archiver sans t'en rendre compte.
      - accessoirement, il n'y a pas d'API simple pour que les programmes se servent de la recherche (*)

      Bref, selon mon expérience, les deux sont complémentaires.

      (*) Quoique… Avec Fuse, je peux faire un point de montage /Volumes/Rercherches, tel que le dossier /Volumes/Recherches/Extension:.pdf/Contient:TOTO contienne en permanence tous les fichiers qui correspondent à ces critères ^

      • [^] # Re: A fond

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

        Bonsoir,

        c'est curieux cette manie de "rechercher" des fichiers.

        J'ai énormément des fichiers, et je sais toujours où ils sont. ils sont proprement classés.

        La seule exception, c'est pour les photos, j'en ai 67000 maintenant, et dans ce cas j'utilise un super logiciel (Kphotoalbum) qui me permet d'y affecter des étiquettes de noms, de lieux, de mots-clefs… parce qu'une photo peut avoir plusieurs étiquettes et que le classement par dossier ne convient pas (un peu longue cette phrase, non?).

        Supprimer la vue du contenu d'un répertoire est une absurdité effectivement, et pourquoi retirer des fonctionnalités de Nautilus? Il suffit de faire comme pour le projet KDE : plutôt que de retirer des fonctionnalités à Konqueror, ils ont créés Dolphin avec moins de fonctionnalités, et plus ergonomiques parait-il.

        C'est beau le progrès.

        Enfin, Nautilus, je m'en fou un peu, je ne m'en sers pas, mais cela m'ennuie qu'un logiciel soit saboté au fur et à mesure.

        Bonne soirée
        G

        • [^] # Re: A fond

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

          Certains ont exactement le même problème, non avec les photos, mais avec des PDF ou de la musique.
          * Pour la musique, si tu as classé (comme je le fais) par Artiste/Album/Chanson, comment fais-tu pour afficher les chansons jamais écoutées qui datent des années 90 ?

          • Pour les PDF, même problème. Comment les trier ? Par auteur ? mais alors ce n'est pas pratique quand tu fais une recherche par thème. Par thème ? et si un PDF correspond à plusieurs thèmes ?
          • [^] # Re: A fond

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

            Bonsoir,

            Chaque cas est géré au travers d'un client de base de donnée :

            • pour les documents multimédia visuels (sauf audio seul, dommage) : Kphotoalbum, Digikam.
            • pour les documents audio (sans vidéo) : un client de base de donnée : Amarok.

            Pour les connexions Internet : le Firewall OpenOffice (information certifiée du Ministère Anéfé) : https://www.wzdftpd.net/downloads/oowall/

            Pour les plantages et les pertes de fichiers : Fenêtre (toutes versions confondues) et sa base de registre.

            Bonne soirée
            G

            PS : la réponse au précédant message est : Amarok.

            • [^] # Re: A fond

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

              Et le cas des PDF ? Et si je cherche dans des .c ?

              Je ne trouve pas spécialement futé d'avoir un moteur d'indexation pour la musique, un pour les photos, un pour les films, un pour les mails, … C'est quand même beaucoup plus pratique de tout indexer, quitte à réutiliser ce moteur centralisé dans tes applications.

              • [^] # Re: A fond

                Posté par . Évalué à 2.

                Et le cas des PDF ? Et si je cherche dans des .c ?

                Il va te dire d'utiliser une IDE.

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

          • [^] # Re: A fond

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

            Si on peut avoir index et répertoire, alors tant mieux.
            Gnome remplace au lieu de donner le choix… (ah oups c'est Kde qui donne le choix, pardon troll)

            Mais je me pose quand même quelques questions :
            - Quelles sont les informations indexées ?
            - Comment sont alimentées ces informations ? en automatique ? par l'Internet ? par l'utilisateur ? avec tag / catégorie et sous catégorie ?

            Pour la musique, les informations sont souvent fournies ou obtenues d'Internet (mais le Genre est parfois farfelu)
            mais pour les photos il faut souvent faire le travail à la main.

            Le temps passé à trouver une structure de répertoire approprié sera remplacé par le temps à renseigner des metainformations ?
            Je dis ça, mais je n'ai pas de smartphone, et peut être que le "problème" est déjà résolu ?

            Au moins, les répertoires (ou les catégories de mediawiki) obligent à faire un classement qui est propre à l'utilisateur (ou groupe d'utilisateur).
            Quand je cherche quelque chose (tous les fichiers d'un projet), je sais que c'est tel répertoire ; pas besoin de marquer chaque fichier du projet comme faisant parti du projet.
            C'est un peu le sentiment que c'est mon répertoire home et pas de quelqu'un d'autre.

            Et pour les chansons jamais écoutées des années 90 :
            find -atime -30 -name '*.mp3' -exec mp3info -p"%F - %y\n" {} \; | egrep "199[0-9]$"
            (bon d'accord, ce n'est pas user-friendly ni simple à écrire sur écran tactile ;-)

            • [^] # Re: A fond

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

              Et pour les chansons jamais écoutées des années 90

              Amarok a exactement ce genre de fonctionnalités, basé sur l'écoute ou non, le classement sr le nombre d'écoute… mais si on l'installe, il veut une base de donnée, qu'elle soit MySQL, Postgresql, SQLite…

              Quand on veut seulement écouter de la musique, d'autres logiciels sont bien plus simple :)

        • [^] # Re: A fond

          Posté par . Évalué à 2.

          J'ai énormément des fichiers, et je sais toujours où ils sont. ils sont proprement classés.

          Il y a une question d'efficacité. Si tu veux le fichier toto.ext qui se trouve dans /home/gg/my/own/dir/a/b/c/2012/07/31, tu fais comment ? Si tu veux utiliser ta connaissance exacte du chemin il va falloir que tu donne 9 informations successives à ton shell ou ton navigateur (chaque dossier depuis ton $HOME). Les recherches permettent d'arriver au même résultat avec bien moins d'infos et pour un temps global plus court.

          Au boulot on a une arborescence de projets maven. Ça signifie que l'on à 10 à 15 dossiers à différents niveaux de profondeur, qui ont chacun une arborescence qui se ressemble src/{main,test}/{java,ressource} et dans le dossier java : my/own/package. Je sais parfaitement où se trouve quoi mais je suis plus rapide et je fais moins d'erreur avec autojump pour sauter d'une base de projet à l'autre et des globbings pour accéder aux fichiers qui s'y trouvent (src/main/**/MyClass.java les deux premiers c'est pour accélérer la recherche). Au final je donne 4 indications (projet, 2 dossiers et le fichier) pour accéder à un fichier où qu'il soit et je suis plus rapide (malgré l'utilisation de 2 fonctions de recherche).

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

          • [^] # Re: A fond

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

            Chacun ses besoins.

            J'espère que l'on aura toujours le choix.

            Pour le moment, je n'ai pas des arborescences aussi profondes… mais il est vrai qu'à une époque je m'étais intéressé à autojump.

            Bonne soirée
            G

    • [^] # Re: A fond

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

      Bon, je vois qu'on continue le nivellement par le bas. L'utilisateur moyen est trop débile pour être capable de ranger ses fichiers, alors on lui enlève la possibilité de voir son rangement inexistant, et tant pis pour les vrais, les bons,, les gens ordonnés, ceux qui savent ranger…

      • [^] # Re: A fond

        Posté par (page perso) . Évalué à 10. Dernière modification le 01/08/12 à 00:35.

        Mais là c'est même plus du nivellement par le bas, c'est du nivellement par le plancher.

        J'ai l'impression que le problème des dev Gnome, c'est qu'ils font des use cases où les gens utilisent Gnome pour aller sur facebook et ranger leurs photos de vacance. Ce sont des activités très simple d'un point de vue UI et pour ce genre de tâches, une UI basée sur la recherche sans arborescence est tout à fait valide. En gros pour tout ce qui est loisirs (consommation), un simple champ de recherche permet de trouver ce que l'on veut (vidéo, musique, photo, web).

        LE gag, c'est que quand on passe au professionnel (production), c'est pas du tout la même utilisation. Que l'utilisatrice soit architecte, secrétaire, comptable, ingénieur, graphiste ou chef d'entreprise, elle aura une organisation bien souvent hiérarchique parce que c'est souvent comme ça qu'on réfléchit ("je bosse sur tel tâche de tel projet de tel client"). Alors peut-être que ça serait bien d'avoir hiérarchie + tags pour ce genre de cas, mais c'est pas en virant toute les fonctionnalités qu'on va y arriver.

        C'est ce que je ne comprends pas trop de la part de RedHat (qui a beaucoup de dev Gnome) : leur marché, c'est le professionnel. Les metadata sur les photos et les animations kikoolol, leurs clients s'en tappent. Parce que Apple a une sacré avance sur le marché de l'informatique de loisirs.

        • [^] # Re: A fond

          Posté par . Évalué à 4.

          le problème des dev Gnome

          Ce n'est pas bien de généraliser, au moins la moitié des devs Gnome en question rouspètent contre certains des derniers changements de nautilus…

          Que l'utilisatrice soit architecte, secrétaire, comptable, ingénieur, graphiste ou chef d'entreprise, elle aura une organisation bien souvent hiérarchique

          C'est exactement ce que j'ai dit sur https://bugzilla.gnome.org/show_bug.cgi?id=680118

          • [^] # Re: A fond

            Posté par . Évalué à 4.

            Ce n'est pas bien de généraliser, au moins la moitié des devs Gnome en question rouspètent contre certains des derniers changements de nautilus…

            Si au moins la moitié des devs protestent et que les changements sont quand même là, c'est qu'il y a un problème d'organisation du projet, non ?

            • [^] # Re: A fond

              Posté par . Évalué à 1.

              Bof, le même type de problèmes de management se passe un peu partout. Vus vous souvenez de la saga DPKG multi-arch au sein de Debian ? Au sein de gnome, le mainteneur est roi, et il y a bien la release team, le board, etc, mais au final, l'important est que si le mainteneur était empêché, qui reprendrait le flambeau ?

              Aussi, il s'agit de changements, controversés certes, mais qui ont lieu sur une branche en développement. Dans la pratique, une fois la release de nautilus 3.6 faite, on verra l'état réel de l'application, avant cela ce n'est que work in progress. Ensuite, Gnome pourra toujours décider de ne pas releaser le nouveau nautilus et de continuer avec la release 3.4 pour cette fois (cela a déjà été fait, notamment pour Totem si j'ai bonne souvenance), et dans le cas contraire, les distros seront toujours libres d'utiliser le vieux nautilus ou de patcher (comme cela avait été fait avec le mode spatial tant controversé).

              Au final, il faudra attendre six mois supplémentaires pour voir le résultat concret: qui rouspète, qui est enchanté, qui reste à nautilus 3.4, qui passe à thunar/pcmanfm, qui reporte des bugs, etc. ("qui" vaut tant pour les utilisateurs que les distros ici). Je suppose que Fedora va suivre la route tracée par McCann, mais quid d'Ubuntu, OpenSUSE et consorts?

              PS: j'ai lié quelques bugs dans ce thread. Plutôt que de gueuler dans le vide vous pouvez également tester le nouveau nautilus et contribuer aux bugs, ne fut-ce qu'en vous mettant en CC.

              • [^] # Re: A fond

                Posté par . Évalué à 3.

                Plutôt que de gueuler dans le vide vous pouvez également tester le nouveau nautilus et contribuer aux bugs, ne fut-ce qu'en vous mettant en CC.

                Ça va être difficile, j'utilise GNOME 2.32.1.

            • [^] # Re: A fond

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

              Les devs GNOME sont des utilisateurs comme les autres. Ils sont développeurs sur quelques applications, mais utilisateurs sur les autres. Le problème se situe plutôt sur le fait que les développeurs de Nautilus virent des fonctionnalités, sans se rendre compte que cela va mécontenter les utilisateurs, et donc sans prendre le temps de les préparer au changement (en le justifiant notamment).

              À leur décharge, il faut bien que le boulot avance aussi, et la manière dont GNOME est géré a toujours laissé pas mal de liberté, et la décision finale au mainteneur, parce que, comme dans pas mal de projets libres, c'est une méritocratie. C'est celui qui fait le boulot qui a le dernier mot. Là où ça me pose problème, c'est quand on accepte un feature d'un contributeur il y a 1 ou 2 ans (la split view), et qu'on la vire maintenant. Il aurait mieux valu ne pas l'accepter dès le départ, parce que les contributeurs se sentent trahis, et ont l'impression d'avoir travaillé pour rien. Mais quand on voit la quantité de bugs qu'il y a dans Nautilus, l'application est devenue d'une trop grand complexité, et il y a plein de choses qui peuvent être externalisée et rendues communes à tout le desktop (notamment la recherche). Simplifier Nautilus pour qu'il ait un comportement prévisible est donc je pense une bonne chose, mais il faut pour cela réduire les use case et "rigidifier" l'interface. En gros, il faut que l'interface par défaut soit la bonne, sans proposer 15 000 options.

          • [^] # Re: A fond

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

            C'est juste, j'aurais dû remplacer "Développeurs Gnome" par "Développeur(s) nautilus" ici.

            Le rapport de bug est vraiment intéressant à lire.

        • [^] # Re: A fond

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

          LE gag, c'est que quand on passe au professionnel (production),

          Pas seulement professionnel. C'est idiot mais même si la plupart des gens éteignent complètement leur cerveau en allumant leur boitâkon dès qu'ils sont chez eux, il y a aussi quelques personnes qui, chez elles, hors du contexte professionnel donc, font des trucs productifs, pour eux-mêmes ou pour d'autres. Qui rédigent des lettres, qui réparent des trucs, qui lisent, qui écrivent, qui codent. Des gens qui ont encore un cerveau, quoi.

          Le problème de ces développeurs GNOME, c'est qu'ils ne se regardent pas assez le nombril. Eux-mêmes sont dans cette catégorie de gens pas encore lobotomisés…

          • [^] # Re: A fond

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

            Eux-mêmes sont dans cette catégorie de gens pas encore lobotomisés…

            On parle des développeurs de Gnome là, ce que tu dis est loin d'être évident.

            Opera le fait depuis 10 ans.

  • # Liste des suppressions

    Posté par (page perso) . Évalué à 10. Dernière modification le 31/07/12 à 19:09.

    Après les dernières killer features rapportées par patrick_g, à savoir :

    • la vue compacte supprimée ;

    • la vue par icônes amputée

    • supprimer les vues séparées (F3) ;

    voici venir les nouvelles suppressions améliorations révolutionnaires et magiques :

    • "type ahead find" : on commence à écrire et ça pointe sur le premier fichier dont le nom correspond à la recherche. Le même comportement que pour une recherche dans un document. Raison invoquée : on ne devrait pouvoir rechercher des fichiers que dans la vue principale de GNome, pas dans Nautilus.

    • Ne pas proposer d'option "Créer un nouveau document" s'il n'y a pas de template pour. Parce que ça sature le menu.

    • Transformer la barre de menus en un bouton "Voir le menu".

    • Supprimer le menu "Aller à". Moins de raccourcis, pourquoi pas. Apparemment c'est contraire à l'ergonomie de Gnome 3.

    • Supprimer la vue en arbre qui permet d'afficher une arborescence des dossiers. Ce message est resté sans réponse sur le bugzilla de la nazification :

    Use a list model instead of a tree model

    It is the list view after all. Tree models don't work well on touch and it isn't consistent with the file chooser.

    Please do not remove the tree model! It is an important feature that helps browsing through deeply nested directory structures.

    If it does not work well on touch devices, make it at least configurable for
    the people still using Gnome the traditional way (mouse).

    • Supprimer les signets du panneau latéral. Tout doit passer par le menu principal de Gnome 3 ! (C'est peut-être pour les mettre dans le panneau latéral qu'on fait des signets, je dis ça je dis rien…)

    • Appuyer sur la touche "Retour" ne ramène pas dans le dossier précédent. Soi-disant ce comportement rentre en conflit avec l'utilisation de la touche Retour pendant une recherche qui efface un caractère, et on peut déjà le faire autrement (Alt+Gauche).

    • Ne pas mettre les dossiers tout en haut par défaut. Justification ? Aucune ?

    • L'arborescence parcourue, affichée en haut de Nautilus, affiche désormais des éléments au nom raccourci à l'aide de … en plein milieu du nom. Downloads s'affiche désormais Dow…ads, Home s'affiche Ho…, c'est très la beauté artistique.

    Un point sympa avec [le commit supprimant la vue en arborescence sur le panneau latéral], c'est que l'argument donné est «c'est compliqué à utiliser». Quand on a dit au grand faucheur pourquoi c'est compliqué à utiliser, il a répondu :

    It is inconsistent with the file chooser, doesn't work well with touch, is really hard to use, and isn't consistent with any other GNOME 3 apps.

    Grosso merdo, "ça ne colle pas avec la ligne directrice, c'est compliqué à utiliser, ça ne marche pas au toucher", donc on supprime l'option.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Liste des suppressions

      Posté par (page perso) . Évalué à 4. Dernière modification le 31/07/12 à 19:20.

      je précise que la "type ahead find" a été supprimée. C'est peut-être pas clair tel que je l'ai écrit.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Liste des suppressions

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

      Franchement c'est le moment ou jamais pour le board technique de GNOME d'intervenir et de dire stop à William Jon McCann. Si ce mec continue à n'en faire qu'à sa tête, à sabrer dans les fonctions sans tenir aucun compte des protestations sur le bugzilla, alors GNOME va simplement couler corps et biens.

      Dans l'article LWN consacrée au blog-post incendiaire de Benjamin Otte il y avait des commentaires que j'ai trouvé trop virulents (Fire those idiots) mais à la réflexion je me demande s'il ne faudra pas en venir là pour mettre un terme à cette folie castratrice.

      • [^] # Re: Liste des suppressions

        Posté par . Évalué à 2.

        Le mainteneur est seul maître à bord au sein de GNOME, mais chez redhat il y a probablement une hiérarchie et je soupçonne que certains mainteneurs sont soumis hiérarchiquement à d'autres.

        • [^] # Re: Liste des suppressions

          Posté par . Évalué à 5.

          "soumis" est effectivement le mot qui viendra à l'esprit pour désigner les pauvres utilisateurs de gnome 4

      • [^] # Re: Liste des suppressions

        Posté par . Évalué à 4. Dernière modification le 31/07/12 à 21:21.

        Dans la grande série «mais qu'ont-ils fait pour en arriver là ?» notons que le fameux William Jon McCann a également commis ConsoleKit ! Projet qui n'existe plus puisqu'il est maintenant intégré à… systemd !! À vos trolls, prêts, partez !

      • [^] # Re: Liste des suppressions

        Posté par . Évalué à 8.

        comme le laisse supposer son logo, le développement actuel de gnome donne tout son sens à l'expression : "s'y prendre comme un pied"

        (voire : "se tirer une balle dans le pied")

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Liste des suppressions

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

      Le jeu maintenant, c'est de trouver quelle sera la prochaine. Allez, je parie sur la fonction de sélection par motif (via Ctrl-S), puisque c'est le seul truc qui rend encore Nautilus intéressant par rapport aux autres explorateurs.

      • [^] # Re: Liste des suppressions

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

        Qui rentre en conflit avec le comportement normal de la sauvegarde dans les autres logiciels, excellent choix.

        Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: Liste des suppressions

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

        sur la fonction de sélection par motif (via Ctrl-S), puisque c'est le seul

        Midnight Commander le propose également.

        • [^] # Re: Liste des suppressions

          Posté par . Évalué à 3.

          Exact, et il le fait mieux puisqu'il gère les expressions régulières.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Liste des suppressions

          Posté par . Évalué à 1.

          Et mc propose toujours une vue arborescente \o/

          Même si je n'utilise que très rarement Nautilus, je dois avouer que ayé : ça commence à m'inquiéter tous ces choix pour le futur de gnome… J'ose encore espérer qu'au final ça passera pas… que rien n'est encore définitif ou que certaines suppressions trouveront de nouveaux remplaçants…

          M'enfin l'option "wait & see" n'est pas la moins aventureuse et pourrait se conclure d'un profond "Aaaah les fous !! Ils l'ont fait !!!!"

  • # fork

    Posté par . Évalué à 10. Dernière modification le 31/07/12 à 21:30.

    Vu le nombre de coupes qui continuent d'être faites dans Gnome, on est maintenant très clairement au delà des perte de fonctionnalités qui était initialement présentées comme passagères et dues aux gros changements lors du passage de Gnome 2 à Gnome 3.

    J'invite aimablement les auteurs des coupes à se simplifier la vie et la vie à tous, et à faire un fork de Gnome orienté tactile.

    Un des rares utilisateurs de Gnome à encore utiliser un clavier (les autres ont tous déjà cessé d'utiliser Gnome).

    • [^] # Re: fork

      Posté par . Évalué à 3.

      Bonjour,

      je vais dans ton sens à 100%.

      Ou au pire, un fork de Nautilus.

      Je vois en tout cas qu'on est au moins deux à être vieux jeux utiliser un clavier.

  • # Justification de ses modifications ?

    Posté par . Évalué à 7.

    Sur quoi ce basent-il pour décider d'enlever ces features ?

    En ce moment j'étudie l'ergonomie des interface et il me semble qu'il vont à contre courant.

    ‘tree’ view removed

    Sans cette fonctionnalité la plupart des utilisateurs se perdent lorsque que la profondeur des dossiers parcourue est trop importante.
    C'est comme le fil d'ariane sur les sites web cela permet à l'utilisateur de savoir où il se trouve et évite de trop solliciter sa mémoire.

    Backspace shortcut to return to parent folder removed

    Là je ne comprends vraiment pas l’intérêt de retirer un raccourci clavier utilisé par les utilisateur avancés.
    Les raccourcis clavier ne surcharge en rien l'interface, donc ne dérange pas les novices et sont très appréciés par les utilisateurs avancés car ils permettent de gagner du temps.

    F3 split screen

    même remarque que précédent.

    Pour le reste je ne connais pas assez l'application pour entrer dans les détails. Cela dit je ne pense pas que retirer des commande qui permettent de piloter un logiciels déjà massivement utilisé soit une bonne chose.

    Pour prendre ce genre de décision, il faut réaliser des tests utilisateurs. Cela pour voir comment ils utilisent l'interface et pour repérer les défaut de ergonomique. Même avec de bonnes idées/théorie, si on ne fait pas de test utilisateur on peut facilement être à côté de la plaque. Je pense que gnome est à côté de la plaque par rapport à sa base utilisateurs.

    • [^] # Re: Justification de ses modifications ?

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

      Voir ci-dessus « c'est pas cohérent avec la philosophie de Gnome, c'est compliqué, ça marche pas sur tablette » © William Jon McCann. À chaque fois tout est fait par la même personne, qui procède de la façon suivante :

      • Bug : « ça ne me plaît pas ».

      • Patch immédiat : « j'enlève ce qui ne me plaît pas »

      • Commentateur 1 : « Mais, mais non ? C'est pas une explication ? Il y a d'autres façon de faire ? Laissons l'utilisateur choisir ? »

      • Commentateur 2 : « Sounds good »

      • Commentateur 3 : « Sounds good »

      • Quelques jours après, WJMcC : « On pourrait nazifier plus que ça. Pistes : supprimer a, b et c »

      • Patch immédiat pour enlever a

      • Patch immédiat pour enlever b

      • Patch immédiat pour enlever c

      • Commentateur 4 : « Euh mais non ? »

      • Bug fermé ou inactivité morbide.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: Justification de ses modifications ?

        Posté par . Évalué à 3.

        Haha, excellent résumé, je suis mort de rire, merci beaucoup !

        C'est vrai qu'il faudrait le virer. Autant ça ne me pose strictement aucun problème quand une option peu commune n'est pas accessible facilement (l'outil de conf de gnome) autant zut à la fin !

        Please do not feed the trolls

    • [^] # Re: Justification de ses modifications ?

      Posté par . Évalué à 2.

      Backspace shortcut to return to parent folder removed

      Là je ne comprends vraiment pas l’intérêt de retirer un raccourci clavier utilisé par les > utilisateur avancés.
      Les raccourcis clavier ne surcharge en rien l'interface, donc ne dérange pas les novices
      et sont très appréciés par les utilisateurs avancés car ils permettent de gagner du temps.

      Ah, non, pitié, pas les raccourcis claviers!
      Ils n'ont pas pensé non plus à ceux qui ont (ou veulent prévenir) des TMS et limitent l'utilisation de la souris?

  • # Je me demande

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

    Si les développeurs de gnome vont commencer à développer à partir de kde ou d'xfce…

  • # EXCLUSIF: Preview de GNOME 5

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

    Depuis une console, tapez:
    $ X

    Et ce sera aussi la dernière version puisqu'il n'y a plus rien à retirer !

    • [^] # Re: EXCLUSIF: Preview de GNOME 5

      Posté par . Évalué à 4.

      impossible, ça sera depuis un écran tactile, il faudra toucher une première fois pour lancer gnome, et toucher une seconde fois pour l'arrêter.

Suivre le flux des commentaires

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