Journal Gnome 3 : cachez ce bug que je ne saurais voir

Posté par  (site web personnel) .
Étiquettes :
11
29
mar.
2012

En lisant la dépêche sur gnome je me suis dit, tiens, je vais rajouter mon bug préféré à la liste du every details matters, mais voilà que rapidement mon ajout est révoqué, avec comme commentaire « https://linuxfr.org/news/gnome-3-4-l-emergence-des-applications ».

Diantre, me dis-je. Demandons lui plus de détails par mail :

Hello,

You removed the line I added in the Every Detail Matters list, with the
comment "the last update added a bug that is out of scope". So I wanted
to know what you mean exactly about that.

Is it the "Window picker" section which is not accurate ? If that's it,
may be you could tell me which section would be accurate to add this bug
in the list.

kind regards, […]

Hey Mathieu,

Sorry about removing your bug. Couple of reasons for that - first,
every detail matters is currently closed (the last round finished with
the end of the 3.4 development cycle). Second, your bug was about the
file chooser, but every detail matters was only for the activities
overview.

I did look for you on IRC to try and explain…

Hope you understand,

Allan

Bon, ok, soit.

Je retourne donc à la lecture de mes mails, et que ne vois-je pas ? une activité sur mon bug favoris ! Qu'est-ce, mon intervention aurait-elle motivé un développeur gnome à zieuter le problème ? Hélas, mille fois hélas, non, simplement :

André Klapper <a9016009> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|High                        |Normal
                 CC|                            |a9016009@gmx.de
            Version|2.6.x                       |3.4.x

Alors soit la version est mise-à-jour, mais au passage on rabaisse la priorité subrepticement.

Bon, aller, je ferait mieux de contribuer à clore des bugs gnome-love qui devraient être à ma porté.

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Ça dénonce…

      Posté par  . Évalué à 7.

      Mouais, enfin là il y a quand même un patch de proposé il y a 4 ans, qui a été testé par 2 personnes depuis. Ce genre de bug, dans les gros projets, reste ouvert parce qu'en général le problème est simple mais la solution est longue, complexe, ou incertaine. Là on a une solution, mais il y a une sorte de dédain inexplicable par rapport à ce problème.

      D'ailleurs la prochaine étape est facilement prévisible: "Gtk est passé en version xxx, et le code a pas mal changé, il faudrait refaire un patch." Forcément, s'ils n'attendaient pas 2 ans entre chaque réponse, le patch aurait été valide…
      Pourquoi dans ce cas ne pas être courageux et sincère, et le clore "Won't fix" ? Avec comme raison "J'ai pas envie.".

      • [^] # Re: Ça dénonce…

        Posté par  . Évalué à 1.

        Pourquoi poser la question ici et ne pas leur demander directement ?

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

        • [^] # Re: Ça dénonce…

          Posté par  . Évalué à 3.

          Parce que mon commentaire n'est pas particulièrement constructif…

          • [^] # Re: Ça dénonce…

            Posté par  . Évalué à 3.

            Il y a quoi de non constructif dans une question du genre « pourquoi ce bug n'est-il toujours pas résolu alors qu'un patch a été soumis ? ».

            Et il ne serait pas moins constructif d'en poser une seconde « si l'on soumet un nouveau patch, est-ce qu'il sera intégré ? Si non, pourquoi ? ».

            En gros, demander des précisions tout en restant factuel.

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

            • [^] # Re: Ça dénonce…

              Posté par  . Évalué à 6.

              Cette question a déjà été posée dans les commentaires du bug. Sans réponse. La poser encore et encore présente peu d'intérêt, à part énerver les gens…

              Le gars qui a proposé son patch (une première version brouillon, une deuxième version mise à jour et un peu plus correcte) a demandé une review rapide, car la taille du patch fait qu'il vaut mieux le peaufiner tant que le code de Gtk/Gnome n'a pas trop changé. Aucun retour.

              Dès lors, je ne vois pas vraiment quoi dire en commentaire à ce bug.

              • [^] # Re: Ça dénonce…

                Posté par  . Évalué à 2.

                Quand je parlais de poser la question, je pensais à le demander directement au développeur, pas dans le rapport de bug. Justement, l'idée, c'est de forcer les dév à au moins expliquer pourquoi ils ne s'en occupent pas.

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

        • [^] # Re: Ça dénonce…

          Posté par  . Évalué à 2.

          Parce que vu qu'ils font tout pour l'occulter quand on leur demande poliment, il y a des chances que ça ne va être mieux si on essaye de leur mettre le nez dans le caca.

          • [^] # Re: Ça dénonce…

            Posté par  . Évalué à 1.

            Je ne connais pas l'organisation de GNOME, mais n'y a-t-il pas une personne assez haut placée pour trancher, une sorte de dictateur bienveillant ?

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

      • [^] # Re: Ça dénonce…

        Posté par  (site web personnel) . Évalué à 5.

        Tu m'a donné envie de regarder mes patchs en attente sur le bugzilla de GNOME et cela m'attriste :(

        https://bugzilla.gnome.org/show_bug.cgi?id=136294
        https://bugzilla.gnome.org/show_bug.cgi?id=616198

        Bon a coté il faut voir tout ceux qui ont été acceptés rapidement…

  • # Le problème n'est-il pas pris à l'envers ?

    Posté par  . Évalué à 6.

    J'ai passé toutes mes machines ainsi que celles que j'administre en simple-clic, en disant à mes utilisateur d'oublier le double clic. C'est super bien accueilli malgré l'incompréhension de départ, mais j'ai évidemment des plaintes par rapport à GtkFileChooser…

    La position des décideurs (que je partage, bien que je n'apprécie pas la façon de faire) semble être la suivante : La configuration de GtkFileChooser ne doit pas dépendre de la configuration de Nautilus.

    Le choix "simple-clic" ou "double-clic" ne devrait-il pas se situer dans les paramètres de Gnome ? Du coup chaque application se baserait sur cette configuration afin d'adapter son comportement : Nautilus, GtkFileChooser, …

    Quelqu'un peut me dire si je suis à côté de la plaque ?

    • [^] # Re: Le problème n'est-il pas pris à l'envers ?

      Posté par  . Évalué à 6. Dernière modification le 30 mars 2012 à 11:40.

      Je suis d'accord avec toi. Il y a au moins trois façons de voir les choses:

      1. C'est GTK la base, et donc ce genre de comportement devrait être spécifié au niveau GTK: montrer d'abord les dossier, montrer les fichiers cachés par défaut, single click… Dans ce cas, il faut tout mettre coté GTK, et faire en sorte que Nautilus ne fasse qu'utiliser ces préférences.

      2. Le GtkFileChooser n'est qu'un outil, qui devrait s'adapter à l'environnement par le biais d'une API ou d'une config adaptée. Dans ce cas, on met la configuration dans Gnome (pas seulement Nautilus), et on a du coup un environnement de bureau cohérent au niveau Gtk.

      3. Le GtkFileChooser a son propre comportement, un peu comme le fait qu'une appli Qt dans Gnome va appliquer son propre thème. Gnome devrait donc implémenter son propre GnomeFileChooser, qui aurait le comportement qui va bien. Comme au point 2., ceci dit, il mettre la configuration au niveau de Nautilus n'est pas idéal, et il faut la mettre au niveau Gnome.

      C'est un peu lorsque Nautilus gérait le fond d'écran: c'était une préférence de Nautilus. WTF? C'était brouillon, mais au moins ça marchait… et ça peut être peaufiné plus tard, de toutes façons.

      N'importe laquelle de ces solutions améliorerait la situation actuelle…

    • [^] # Re: Le problème n'est-il pas pris à l'envers ?

      Posté par  . Évalué à 6.

      La position des décideurs (que je partage, bien que je n'apprécie pas la façon de faire) semble être la suivante : La configuration de GtkFileChooser ne doit pas dépendre de la configuration de Nautilus.

      La position de départ semble être encore plus de principe que ça:

      The file chooser is different from the file manager; in the former you click on a file, then click the OK button to accept the operation.

      Le comportement par défaut (de l'utilisateur, pas de l'outil) doit être de sélectionner un fichier puis cliquer sur le bouton. Donc le simple clic viendrait foutre en l'air cette vision parfaite des choses.

      J'ai d'ailleurs eu la surprise de ce comportement pas plus tard qu'il y a une heure.
      Je voulais uploader un fichier dans firefox. Celui a lancé le file selector gtk.
      Je choisis images dans les emplacements, je choisis ensuite un dossier dans celui ci en cliquant dessus, je n'entre pas dans le dossier (pas de simple clic) mais le dossier est bien sélectionné, et là je regarde le bouton, il s'appelle Enregistrer, cool, je clique dessus pour enregistrer mon fichier et rien ne se passe, la fenêtre de dialogue reste là.
      Uh? Ah non, je suis dans le dossier précédemment sélectionné, le bouton enregistrer sert en fait à entrer dans les dossiers. Une fois dans le dossier, j'ai hésité à cliquer sur enregistrer parce que je n'étais plus certain de ce qu'il produirait.
      Bon, ça a marché, mais je ne feins pas la surprise, c'est vraiment ce qui s'est passé.

      Un autre truc marrant dans le même genre.
      Dans gimp, ayant compris le comportement précédent, je veux enregistrer un fichier. Je clique sur le bouton home en haut, je vois apparaitre tous les dossiers utilisateurs et le mien 'imr' est sélectionné ("surligné"). Je clique enregistrer pour rentrer dedans et ben non, il essaie d'enregistrer le fichier dans home et ne rentre pas dans 'imr' cette fois.
      En fait, il y a 2 niveaux de surlignage, celui qui apparaissait n'était pas le bon (pas assez foncé) et je ne sais pas à quoi il correspond. Il fallait cliquer sur 'imr' pour qu'il devienne un peu plus foncé puis cliquer sur enregistrer pour rentrer dans le dossier.

      C'est super marrant de voir que toutes ces inconsistences sont faites au nom de la consistence.

      Maintenant, il ne faut pas croire que dans l'autre sens c'est exempt de problème.
      Dans le file selector de KDE, je suis en simple clic, je clique un dossier, il s'ouvre et j'enregistre dedans en cliquant sur OK.
      Ca roule.
      Par contre, je peux sélectionner un dossier en ctrl + cliquant dessus OU en cliquant droit dessus (et éventuellement effectuer les opérations du menu contextuels dispos) et en cliquant ensuite dans un espace blanc de la fenêtre de dialogue. Le dossier reste sélectionné (surligné) mais si je clique sur OK, le fichier va aller dans le dossier où le dialogue est, pas dans le dossier sélectionné.
      En fait le surlignage n'a aucun effet dans ce cas.

      C'est un cas moins perturbant parce qu'on peu de gens ont recours au ctrl + clic ou au clic droit contextuel dans ce cas vu que l'utilisation du file selector en simple clic + OK est suffisament directe pour qu'on n'ait pas recours à autre chose, mais ça montre tous les cas de figure dans lesquels on peut se retrouver.
      Il y a par exemple une belle cagade avec ark quand on est en simple clic. Il faudrait une option pour qu'il travaille en double clic.

Suivre le flux des commentaires

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