Journal Perte de CTRL

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
33
29
déc.
2013

Bonjour nal,

Je te fais part d'un problème qui m'est arrivé suite à une upgrade et qui pourrait t'arriver aussi. En creusant un peu, j'ai trouvé l'origine du problème, la solution et le pourquoi du comment.

Suite à une upgrade de ma Debian sid (et plus particulièrement du paquet xkb-data qui contient la liste des dispositions claviers), ma touche CTRL droite ne fonctionnait plus. Or, je m'en sers pour passer d'un bureau à l'autre (via CTRL+F*), et je me voyais mal utiliser le CTRL gauche pour ça (à moins de me tordre la main, mais n'étant pas utilisateur emacs, je n'ai pas cette souplesse naturelle de la main). Bon, au départ, je pensais que ma touche ne fonctionnait plus du tout, mais en fait, l'excellent petit utilitaire xev m'a permis de voir que non. En fait, plutôt que d'être reconnue comme CTRL_R, elle était reconnue comme ISO_Level5_Shift.

Un petit coup de Google et je tombe sur un bug chez Mageia du même genre avec un correctif. Mais quand même, je me demandais bien pourquoi j'avais perdu mon CTRL droit. Je me suis donc mis en quête du pourquoi du comment. Et j'ai trouvé le commit fautif qui a introduit la ligne incriminée dans le bug chez Mageia. En plus, le message de log du commit indique un bug chez Freedesktop (datant de 2008 quand même).

À la lecture de la longue conversation, on se rend compte qu'au départ, c'est parce que CTRL+Espace ne fonctionnait pas dans Rythmbox (ou plutôt bizarrement), et que l'origine venait du layout. Au fur et à mesure, différentes propositions sont faites, dont notamment celle du commit, mais là, quelques uns s'insurgent pour dire que ça rend le comportement du CTRL droit différent du CTRL gauche. Il y a même une proposition pour un layout qui permet à la fois de faire marcher Rythmbox et de conserver un comportement identique pour les deux CTRL. Mais rien n'y fait, celui qui emporte le morceau est celui qui propose de tuer le CTRL droit, au prétexte que sinon, c'est perturbant parce qu'on peut écrire des espaces (au féminin) bizarres sans le vouloir (encore avec AltGr je comprends, mais CTRL…). Et quelques mois plus tard, paf le chien, ça arrive dans ma Debian.

Du coup, j'ai patché comme indiqué chez Mageia, ça marche très bien. Et je sens qu'on n'en a pas fini avec ce bug. C'est vraiment le genre de débat qui peut durer assez longtemps. Et beaucoup de gens vont être impacté, en gros tout ceux qui utilisent la variante "Variante" de la disposition fr, y compris "Variante (latin 9 uniquement)".

  • # same here

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

    J'ai ça dans Archlinux depuis un bon bout de temps maintenant, après une fresh install.
    Du coup, ça pose des soucis pour certaines applis qui utilisent le control droit pour des actions particulières (comme déverrouiller le curseur souris capté par une machine virtuelle dans VirtualBox)
    J'ai toujours trouvé ça débile, un control droit, c'est un control droit.
    Donc, je patch systématiquement à chaque fois que j'installe une archlinux, supaire ! C'est moi qui doit patcher pour retrouver un comportement "normal" et pas ceux qui utilisent Rythmbox.

    • [^] # Re: same here

      Posté par  (Mastodon) . Évalué à 3.

      C'est moi qui doit patcher pour retrouver un comportement "normal" et pas ceux qui utilisent Rythmbox.

      Non, mais en plus, il existe des solutions qui conviendraient à tout le monde, les utilisateurs de VirtualBox comme ceux de Rythmbox. Mais ce n'est pas cette solution qui a été retenue. C'est ça qui est incompréhensible.

  • # de toute façon ce sont des cons chez freedesktop

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

    Ça ne m'étonne pas beaucoup que freedesktop ait introduit ce genre de bogue. Dans la même veine il y a le coup d'avoir fait monter les clés usb qui étaient avant dans /media/clé vers /run/media/utilisateur/clé ce qui est très bête :

    https://igurublog.wordpress.com/2012/03/11/udisks2-another-loss-for-linux/

    https://www.debian-fr.org/retrouver-le-comportement-normal-des-periferiques-montes-t44997.html

    Leur prochain truc c'est de désactiver le clic droit de la souris, parce que steve Jobs trouvait ça trop top moumoutte d'avoir un seul bouton ?

    « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

      Je n'ai pas compris pourquoi c'est très bête.

    • [^] # Re: de toute façon ce sont des cons chez freedesktop

      Posté par  . Évalué à 9.

      C'est plutôt très pratique dès qu'il y a plus de 2 utilisateurs simultanés sur la machine (configuration multi-head). Je n'ai pas envie que n'importe qui puisse lire le contenu de ma clé usb simplement parce que je l'ai branchée.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

        c'était tellement difficile pour eux de rajouter une option pour modifier le comportement par défaut qui était jusque là présent, pour satisfaire le faible pourcentage d'utilisateurs "multihead", plutôt que de tout chambouler pour tout le monde ?

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  . Évalué à 6.

          Pourquoi ce serait le faible pourcentage d'utilisateurs multihead qui devrait avoir à changer une option plutôt que le faible pourcentage d'utilisateurs qui veut garder /media ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  . Évalué à 1. Dernière modification le 29 décembre 2013 à 14:35.

          Euh pour l'utilisateur lambda (: qui n'a aucun script, encore moins avec des chemins spécifiant /media en dur), ça ne change rien du tout.

          Je suis passé de /media à /run/media/, et je cherche encore quel désagrément cela m'aurait provoqué.

          Ah oui : aucun.

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

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  . Évalué à 7.

          Utiliser la méthode la plus sécurisée par défaut ne me semble pas aussi saugrenue que ce que tu présente (discutable peut être, saugrenue je ne trouve pas).

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

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

          Cette option existe. Bon, en revanche, il ne faut pas rêver, c'est un peu compliqué, ça nécessite de bidouiller udev. Comme l'indique la page de manuel udisks(8), il faut le régler pour fixer la propriété suivante :

          UDISKS_FILESYSTEM_SHARED = 1

          Il faut donc une règle udev, qui s'applique à tous les périphériques blocs amovibles, voire à tous les périphériques tout court, c'est plus simple.

      • [^] # Re: de toute façon ce sont des cons chez freedesktop

        Posté par  . Évalué à 2. Dernière modification le 29 décembre 2013 à 17:11.

        Quelle différence avec /media/USB qui appartient à ton utilisateur avec les droits 700 ?

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  . Évalué à 4.

          Comment on fait quand on branche 2-3 clé usb, on les appelle USB-1, USB-2, etc. ? Comment l'utilisateur reconnait laquelle c'est la sienne ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: de toute façon ce sont des cons chez freedesktop

            Posté par  . Évalué à 1.

            1. Les clés USB peuvent avoir un nom
            2. L’utilisateur reconnait la sienne en voyant à laquelle il peut accéder (petit icône type "sens interdit" pour la plupart des systèmes de fichiers en mode graphique, ls -l en terminal)
            3. avec /media/$user/USB, comment faire pour partager une clé entre plusieurs utilisateurs ? (pour /media/USB : chgrp users /media/USB;chmod g+rwx /media/USB)

            • [^] # Re: de toute façon ce sont des cons chez freedesktop

              Posté par  . Évalué à 3.

              Les clés USB peuvent avoir un nom

              Et en pratique, elles sont souvent le nom de la marque, ça fait beaucoup de collision possibles.

              L’utilisateur reconnait la sienne en voyant à laquelle il peut accéder (petit icône type "sens interdit" pour la plupart des systèmes de fichiers en mode graphique, ls -l en terminal)

              Ce n'est pas du plus pratique.

              avec /media/$user/USB, comment faire pour partager une clé entre plusieurs utilisateurs ? (pour /media/USB : chgrp users /media/USB;chmod g+rwx /media/USB)

              Il faudrait changer le groupe de /run/media/$user dans la règle udev idoine et la procédure est la même.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: de toute façon ce sont des cons chez freedesktop

                Posté par  . Évalué à 4.

                Il faudrait changer le groupe de /run/media/$user dans la règle udev idoine et la procédure est la même.

                Si ce n'est qu'il faut modifier les droits de /run/media/$user

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: de toute façon ce sont des cons chez freedesktop

      Posté par  . Évalué à 3.

      http://ignorantguru.github.io/udevil/

      http://pmount.alioth.debian.org/

    • [^] # Re: de toute façon ce sont des cons chez freedesktop

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 30 décembre 2013 à 16:44.

      Alors, /media/$USER/$LABEL, pourquoi pas, c'est plutôt intelligent comme idée. En revanche, /run/media/$USER/$LABEL, c'est stupide, pour plusieurs raisons :

      1. ça n'a absolument rien à faire dans /run, qui est fait pour stocker les fichiers liés à l'exécution de démons, notamment les fichiers de PID et les sockets ;
      2. ça aurait tout à faire dans /media, qui a été inventé pour les montages, ou à la rigueur dans /mnt qui aujourd'hui est fait pour les montages temporaires, même s'il n'a pas été conçu pour avoir des sous-répertoires ;
      3. pour toutes ces raisons, ça viole la FHS sans justification ;
      4. avec cet usage de /run, c'est signé Lennart Poettering, donc c'est mal.

      Moralité, utilisez Debian : un logiciel qui violerait la FHS à ce point serait refusé dans Debian — bug critique pour cause de violation de la charte Debian qui fait référence à la FHS, bloquant pour l'intégration d'une version stable de Debian — et donc patché pour utiliser /media à la place.

      • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

        Moralité, utilisez Debian : un logiciel qui violerait la FHS à ce point serait refusé dans Debian — bug critique pour cause de violation de la charte Debian qui fait référence à la FHS, bloquant pour l'intégration d'une version stable de Debian — et donc patché pour utiliser /media à la place.

        De fait.

      • [^] # Re: de toute façon ce sont des cons chez freedesktop

        Posté par  . Évalué à 2.

        1. ça n'a absolument rien à faire dans /run, qui est fait pour stocker les fichiers liés à l'exécution de démons, notamment les fichiers de PID et les sockets ;

        Déjà que FHS n'est pas toujours très clair (voir assez rarement) et que quand tu pose une question pour essayer de mieux comprendre ben ils ont du mal à être plus claire je doute qu'il y ai quelqu'un qui ai un jour spécifié si formellement /run avec un consensus (en tout cas ce n'est pas ce que dis Debian Policy).

        De plus on peu très bien considérer que ces dossiers sont liés à l'exécution de udev.

        1. ça aurait tout à faire dans /media, qui a été inventé pour les montages, ou à la rigueur dans /mnt qui aujourd'hui est fait pour les montages temporaires, même s'il n'a pas été conçu pour avoir des sous-répertoires ;

        Tout comme les fichiers de pid ont leur place dans /var/run.

        1. pour toutes ces raisons, ça viole la FHS sans justification ;

        Je ne connais pas les raisons qui ont poussé à placer les fichiers PID dans /run, mais je ne vois pas l'intérêt que les dossiers de /media et /mnt soient persistants quand ils sont

        1. avec cet usage de /run, c'est signé Lennart Poettering, donc c'est mal.

        C'est le cas de /run d'une manière général et ça ne l'empêche pas d'être intégré à Debian (tout comme pulseaudio ou tous les *kit qu'il a créé au part avant).

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

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 31 décembre 2013 à 10:45.

          Tout comme les fichiers de pid ont leur place dans /var/run.

          Absolument, mais ça posait des problèmes, résolus par l'ajout d'un répertoire directement sous la racine. Ce répertoire a en outre l'avantage d'avoir réellement un sens, /var étant plutôt conçu pour des données conservées entre les démarrages — voir par exemple /tmp et /var/tmp.

          Je ne connais pas les raisons qui ont poussé à placer les fichiers PID dans /run.

          Aucune, ou en tout cas aucune exprimée. Si tu lis le commit qui a introduit ce changement, et le rapport de bug effectué à ce sujet, tu pourras remarquer qu'aucun, absolument aucun argument n'est indiqué pour justifier l'utilisation de /run/media. Ça n'a ni intérêt ni sens.

          mais je ne vois pas l'intérêt que les dossiers de /media et /mnt soient persistants

          Alors, /mnt c'est clairement fait pour les montages manuels temporaires, qui ne regardent que l'utilisateur, donc c'est hors sujet ici. Pour /media, on peut imaginer un script qui le nettoie au démarrage, en retirant tout les sous-répertoires non mentionnés dans /etc/fstab, vides ou ne contenant qu'un fichier indiquant qu'ils ont été créés par un automonteur, et appartenant à un simple utilisateur. Rien de bien compliqué à faire.

          C'est le cas de /run d'une manière général et ça ne l'empêche pas d'être intégré à Debian (tout comme pulseaudio ou tous les *kit qu'il a créé au part avant).

          Alors, pour /run, il y a une différence majeure : c'est utile. /run/media, c'est inutile, en tout cas on peut le présumer puisque quand on demande aux développeurs amont de justifier cela, ils en sont incapables. Mais ce n'est pas un problème, nettoyer les saletés de certains développeurs amont, on a l'habitude, dans Debian.

          • [^] # Re: de toute façon ce sont des cons chez freedesktop

            Posté par  . Évalué à 3.

            Ça n'a ni intérêt ni sens.

            Je ne suis pas sûr que ça n'ait aucun intérêt le mettre dans /run évite des conflit avec des configuration existantes. Qu'on ne pense pas que ça vaille la peine d'en faire un nouveau dossier est une chose, dire que ça n'a aucun intérêt en est une autre.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: de toute façon ce sont des cons chez freedesktop

            Posté par  . Évalué à 2.

            /var étant plutôt conçu pour des données conservées entre les démarrages

            Tu lis ça où ?
            http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#THEVARHIERARCHY

            Qu'il ne soit pas vidé c'est une chose qu'il soit fait uniquement pour des choses persistante en est une autre.

            Je ne connais pas les raisons qui ont poussé à placer les fichiers PID dans /run.

            Aucune, ou en tout cas aucune exprimée. Si tu lis le commit qui a introduit ce changement, et le rapport de bug effectué à ce sujet, tu pourras remarquer qu'aucun, absolument aucun argument n'est indiqué pour justifier l'utilisation de /run/media. Ça n'a ni intérêt ni sens.

            Et si tu lisais avant de répondre à coté ?

            Pour /media, on peut imaginer un script qui le nettoie au démarrage, en retirant tout les sous-répertoires non mentionnés dans /etc/fstab, vides ou ne contenant qu'un fichier indiquant qu'ils ont été créés par un automonteur, et appartenant à un simple utilisateur. Rien de bien compliqué à faire.

            On peut imaginer pleins de choses.

            Mais ce n'est pas un problème, nettoyer les saletés de certains développeurs amont, on a l'habitude, dans Debian.

            Par contre l'humilité c'est pas encore ça, n'est ce pas ?

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

            • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

              Par contre l'humilité c'est pas encore ça, n'est ce pas ?

              Au contraire : il y a des normes et des consensus, et on s'y soumet, contrairement aux développeurs d'udisks2 ici, qui ont essayé de faire passer en loucedé un changement global de l'arborescence du système de fichier.

              • [^] # Re: de toute façon ce sont des cons chez freedesktop

                Posté par  . Évalué à 5.

                En douce ? Tu les prends pour des imbéciles pour immaginer qu'ils ont pensé que ça ne se verrait pas ?

                Quelque soit la qualité du travail de Debian (que j'apprécie énormément) dire « les développeurs upstream sont souvent des gros cons et nous on est intelligents et on rend leurs logiciels pourri utilisable (ou bien buggé) » c'est de la vantardise.

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

                • [^] # Re: de toute façon ce sont des cons chez freedesktop

                  Posté par  (site web personnel) . Évalué à 1. Dernière modification le 31 décembre 2013 à 16:26.

                  Je n'ai jamais dit que les développeurs amont étaient bêtes ou malveillants, simplement, ce sont des développeurs, avec des compétences et des préoccupations différentes de celles des intégrateurs et des utilisateurs. Un bon développeur amont est généralement un mauvais empaqueteur, et c'est normal.

                  Là en revanche, on a un cas assez particulier, où les développeurs amont on décidé de changer quelque chose sans se rendre compte de l'importance que ça avait, puisque cela touchait à l'arborescence du système de fichier, domaine crucial pour l'intégration d'un système, auquel il n'est pas raisonnable de toucher sans discussion et consensus préalables. Cela leur a ensuite été signalé comme une erreur, mais ils ont maintenu leur choix sans être capables de le justifier. Et ça, c'est crade, mais ce n'est pas grave, comme je disais, les saletés des développeurs amont, ça se patche, ce ne sera pas la première fois, surtout dans ce domaine : le respect de la FHS est probablement le motif le plus fréquent des patchs apportés par Debian aux logiciels empaquetés.

                  • [^] # Re: de toute façon ce sont des cons chez freedesktop

                    Posté par  . Évalué à 3.

                    Là où tu te trompes, c'est en croyant que les développeurs d'udisks sont des devs upstreams pour un logiciel utilisateur. Alors que non, udisks est un logiciel au cœur d'une distro et les devs udisks font donc un travail, justement, d'intégration. La seul différence est que ça se fait au niveau d'un logiciel (et au niveau freedesktop) au lieu de se faire au niveau de la distro.
                    Mais ils ont fait un choix délibéré en se rendant très bien compte de l'importance que ça avait.

                    Et figure toi que cette situation plaît à certains : les distros font chier à prendre ce genre de décisions, et cette mouvance (très liée à systemd, bien sûr) d'unifier ces choix et de les appliquer au niveau de logiciels upstream clés, c'est très bien. Bien sûr, c'est un avis d'utilisateur de Gentoo (qui a pour principe de fournir une série de recettes pour construire son système) et je me doute que la philosophie est différente chez Debian.

                    • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

                      Mais ils ont fait un choix délibéré en se rendant très bien compte de l'importance que ça avait.

                      Sans en discuter, sans l'annoncer, sans le justifier. Bref, je maintiens, on est là dans un très bel exemple de développeur amont qui serait un mauvais empaqueteur, et c'est normal, ce n'est pas ce qu'on lui demande. Les distributions sont là pour s'occuper de pour ce genre de problème, et dans ce cas précis, pour corriger une erreur amont — ce qui est une erreur, ce n'est pas forcément leur choix, s'ils arrivent à le justifier, ce qui n'est pas le cas aujourd'hui, mais la façon lamentable dont il a été effectué et mis en œuvre.

          • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

            nettoyer les saletés de certains développeurs amont, on a l'habitude, dans Debian.

            Genre comme avec OpenSSL ?

            Sans rire, j’aurais cru que cette mésaventure diminuerait un peu l’ardeur des développeurs Debian à patcher à tout va…

            • [^] # Re: de toute façon ce sont des cons chez freedesktop

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

              Le cas OpenSSL c'était une erreur, sans le moindre doute, un cas inverse en fait, où un développeur Debian s'était amusé à faire du travail qui revenait au développeur amont, et l'avait mal fait.

              C'est tout à fait réciproque : en général, un développeur amont ferait un mauvais empaqueteur, et un empaqueteur ferait un mauvais développeur amont.

              • [^] # Re: de toute façon ce sont des cons chez freedesktop

                Posté par  . Évalué à 2.

                Tiens en parlant de la qualité du travail Debian c'est le paquet iceweasel-l10n-fr qui force l'utilisation d'un dictionnaire français bien particulier et qui ne me convient pas (c'est pour ça que je l'ai remarqué) en cherchant (un peu) je n'ai pas trouvé comment c'était fait et donc comment faire pour que mon dictionnaire que j'aime (le « français modern ») soit gardé comme dictionnaire par défaut.

                Tu as une idée ou un pointeur là dessus ? Sinon j'irais voir le mainteneur du paquet.

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

          • [^] # Re: de toute façon ce sont des cons chez freedesktop

            Posté par  (Mastodon) . Évalué à 4.

            Pour /media, on peut imaginer un script qui le nettoie au démarrage,

            Bonjour l'angoisse !

    • [^] # Re: de toute façon ce sont des cons chez freedesktop

      Posté par  . Évalué à 2.

      Leur prochain truc c'est de désactiver le clic droit de la souris, parce que steve Jobs trouvait ça trop top moumoutte d'avoir un seul bouton ?

      Le prochain truc dans ce genre (mais pas des gens de Freedesktop), c’est de supprimer les presse-papiers multiples (avec le passage à Wayland) et par conséquent le copier-coller à la souris parce que les utilisateurs sont trop cons pour comprendre la notion de presse-papiers multiples (mais pas pour trouver /run/media/$USER ? bizarre…) et que de toute façon les applications les gèrent mal (ça, c’est malheureusement vrai dans une certaine mesure, surtout pour des applications basées sur Gtk).

      Quand toutes les bonnes choses auront été supprimées des distributions Linux, seront-elles considérées comme « prêtes pour le bureau » ?

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: de toute façon ce sont des cons chez freedesktop

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 31 décembre 2013 à 08:48.

        parce que les utilisateurs sont trop cons pour comprendre la notion de presse-papiers multiples

        Je ne pense pas que ce changement est (seulement) motivé par un soucis de simplification vis-à-vis d'une certaine confusion des utilisateurs face au double-clipboard, mais surtout parce qu'historiquement, ces deux presse-papiers n'ont jamais cherché à être unifiés "proprement", ce sont deux outils qui ont été ajoutés comme des couches de glaçage sur un gâteau, et du point de vue ergonomique, c'est assez aberrant, même si pratique pour les vieux cons comme moi qui ont bien intégré leur fonctionnement particulier au fil des années d'utilisation, depuis WindowMaker jusqu'au dernier KDE.
        Un véritable presse-papier multiple devrait être plus cohérent et intelligent que cela, on ne devrait pas avoir à se poser la question de "alors, est-ce c'est dans mon presse papier X ou bien celui de mon DE ?", il devrait y avoir les mêmes points d'entrée pour ses invocations (ou bien définir plusieurs points d'entrée simultanés, peu importe).
        Par contre, il me paraît évident que ceux qui veulent supprimer le double presse-papier devrait laisser la possibilité de retrouver ce comportement, sinon ça envoi un message bien triste à la base d'utilisateurs actuelle.

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  . Évalué à 5.

          Par contre, il me paraît évident que ceux qui veulent supprimer le double presse-papier devrait laisser la possibilité de retrouver ce comportement, sinon ça envoi un message bien triste à la base d'utilisateurs actuelle.

          Il me semble avoir lu que c'était possible de le réimplémenter (maintenant, je ne sais pas si ce sera fait).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: de toute façon ce sont des cons chez freedesktop

        Posté par  . Évalué à 3.

        Le prochain truc dans ce genre (mais pas des gens de Freedesktop), c’est de supprimer les presse-papiers multiples (avec le passage à Wayland) et par conséquent le copier-coller à la souris parce que les utilisateurs sont trop cons pour comprendre la notion de presse-papiers multiples (mais pas pour trouver /run/media/$USER ? bizarre…) et que de toute façon les applications les gèrent mal (ça, c’est malheureusement vrai dans une certaine mesure, surtout pour des applications basées sur Gtk).

        Ceux qui sont si bête ce ne seraient pas ceux qui n'ont pas compris que les dév de wayland ne l'ont pas fait juste pour que ce soit géré ailleurs (avec potentiellement plus de souplesse genre ajout d'un troisième type de copier/coller ou avec plus de cohérence avec le reste du bureau) ?

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

        • [^] # Re: de toute façon ce sont des cons chez freedesktop

          Posté par  . Évalué à 3.

          Ou ça ailleurs ?

          Si c’est au niveau du tool kit, ça ne va fonctionner correctement que pour les applications qui utilisent le même.

          Et au niveau du gestionnaire de fenêtres, ça me semble impossible : comment pourrait-il deviner quel texte est sélectionné dans une application ? Et puis ça se heurterait probablement à la sécurité plus sérieuse contre le sniffage de Wayland.

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # même problème sur Fedora

    Posté par  . Évalué à 1.

    Ce bug est vraiment pénible on se demande comment les développeurs qui ont fait ça font un CTRL-PageSup (ou CTRL-PageInf).

    Lors du passage Ubuntu 10.04 vers Fedora 19, j'avais choisi le layout french-alternate habituel (avec son symbole cube au dessus du carré) qui a donc ce problème.

    Finalement je suis revenu au layout classique qui n'a pas ce problème (et qui n'a pas besoin de patch). Après il faudrait voir les autres différences.

    Les vrais naviguent en -42

    • [^] # Re: même problème sur Fedora

      Posté par  (Mastodon) . Évalué à 2.

      Finalement je suis revenu au layout classique qui n'a pas ce problème (et qui n'a pas besoin de patch). Après il faudrait voir les autres différences.

      J'ai essayé le layout fr sans variante, mais il n'a pas les caractères « et » sur AltrGr+W et AltrGr+X (un des deux n'étaient pas le bon). Du coup, j'ai tout de suite cherché une autre solution.

      • [^] # Re: même problème sur Fedora

        Posté par  . Évalué à 2.

        Essaye AltGR+z et AltGr+x (je suppose que le z correspond au mapping w du qwerty…)

        Matricule 23415

      • [^] # Re: même problème sur Fedora

        Posté par  . Évalué à 2. Dernière modification le 30 décembre 2013 à 14:04.

        Tu as essayé OSS ? Il est touché par le bug ?

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

        • [^] # Re: même problème sur Fedora

          Posté par  (Mastodon) . Évalué à 3.

          C'est précisément oss qui est touché par le bug et par ricochet, puisque la plupart des autres (dont la variante Latin 9) dérivent de oss, pas mal de variantes qui sont beaucoup utilisé (et même souvent en config par défaut dans certaines distributions).

      • [^] # Re: même problème sur Fedora

        Posté par  . Évalué à 1. Dernière modification le 03 janvier 2014 à 23:56.

        désolé pour la réponse tardive (en vacances sans d'internet)
        sous Fedora 19, en layout classique, pas de problème pour les AltGr+W et AltGr+X (« et »)
        je ne connaissais pas ce raccourci, merci du tuyau.

        Les vrais naviguent en -42

  • # Local eight level

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

    Le bug sur les espaces : Opinions on nobreakspace / narrow nobreakspace handling

    A l'origine, les gens du layout fr ont pensé qu'il n'était pas nécessaire de mapper la touche RCTL sur un ISO_Shit_Level_Five parce que seule une touche utilisait le niveau 5 : l'espace. Du coup, ils ont ajouté un type spécial pour la touche espace afin qu'elle fonctionne différamment des autres et ne pas perturber l'utilisation de la touche contrôle de droite pour les autres raccourcis.

    manque de pot, le nouveau type modifie aussi le comportement le la touche contrôle de gauche pour l'espace:

    Ok, it seems that despite RControl being used in some types it's not enabled by default. Since enabling RControl as separate modifier is likely to have side-effects somewhere, here is a version that uses plain Control instead

    That means control+space shortcuts will be disabled for fr(oss). I don't see how I could make it better short-term. People are encouraged to make RControl a first-class modifier if they want something less heavy-handed

    en français:

    En fait, il semble que malgré le fait que RCOntrol soit utilisé dans certains types, ce n'est pas activé par défaut. Il est probable qu'activer RControl comme modificateur séparé génère des effets de bords indésirables. Voici une version qui utilise Control tout simplement (sans distrinction gauche droite)

    Cela veut aussi dire que les raccourcis control+espace seront désactivés pour fr(oss). Je ne vois pas comment il est possible de faire mieux a court terme. Si vous voulez quelque chose de moins lourd, je vous encourage a faire de la touche RControl un modificateur de premier niveau.

    Et bien sûr, quelqu'un s'est plaint que et la solution expéditive a été de transformer le layout fr(oss) en layout de niveau 8 complet en désactivant la touche contrôle de droite (afin de pouvoir accéder au niveau 8).

    La bonne solution serait d'avoir LCTL+SPACE agit comme un raccourci clavier et RCTL+SHIFT+SPACE comme une espace insécable fine (et RCTL+SPACE serait désactivé parce que dans le contexte de la touche espace, cela équivaut a un niveau 5, désactivé mais pas disponnible pour les raccourcis clavier). Mais ça n'a pas l'air simple avec xkb (et les histoires de modificateurs primaires / secondaires).

    Le patch qui introduit level4nl et le type LOCAL_EIGHT_LEVEL: https://bugs.freedesktop.org/attachment.cgi?id=16061

    • [^] # Re: Local eight level

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

      Et quand on est plurilingue, on utilise souvent un logiciel qui permet de changer la langue du clavier (ie, un IME comme xim, scim, ou ibus), en appuyant pas mal historiquement sur control et espace. Et que ca ne va plus marcher.

Suivre le flux des commentaires

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