Journal Mes nautilus scripts

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
62
22
jan.
2015

Sommaire

Il était une fois

La possibilité de modifier des fichiers dans le navigateur idoine à l’aide de scripts m’a toujours beaucoup intéressé. Il y a longtemps j’avais d’ailleurs modestement participé au projet g-scripts. Les nautilus scripts me plaisent car il suffit de créer un nouveau fichier dans un dossier spécifique pour que celui-ci soit disponible, un seul fichier, c’est simple (du coup je n’aime pas tellement nautilus-actions ou la solution de thunar… mais c’est une histoire de goût…). Enfin, comme chacun utilise son langage de prédilection, on en trouve partout sur la toile, dans des forums, des forges, des sites ou sections de sites dédiés… C’est en lisant ces scripts que j’ai compris l’intérêt du terminal, que j’ai appris à utiliser la ligne de commande, que j’ai appris quelques notions de code.

Les premiers scripts que j’ai écrit permettaient de convertir des fichiers audio, de tourner des images, d’exporter des svg en png,… des besoins simples mais que les scripts rendaient très faciles d’accès. Un jour, suite à une mauvaise manipulation ou je ne sais quelle maladresse, combinée à une sauvegarde défaillante, j’ai constaté que mon dossier de scripts était vide. Pas très grave puisque pour convertir les fichiers audio j’utilise SoundConverter, je ne fais plus beaucoup de conversion svg→png, pdfmod est très pratique pour manipuler les pdf,…

Oui mais… Mais finalement c’est le retour des svg à convertir, des redimensionnements et conversions d’images,… au départ je lance gimp mais c’est un peu too-much pour une conversion png→jpg. Deuxième étape, je recherche les vieux réflexes dans un man convert, et finalement un jour je fini par me dire, qu’il est temps de refaire le plein de scripts.

La désillusion

Quelques téléchargements de packs de scripts et un peu de tri plus tard, je montre à un collègue linuxien cette possibilité qu’il ne connaissait pas, je partage avec lui ma sélection et là c’est le drame… Il n’utilise pas nautilus mais nemo or certains scripts dont la fonctionnalité m’intéresse utilisent la variable $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS qui a été renommée pour commencer par $NEMO dans le gestionnaire de fichiers de Mint. Qu’à cela ne tienne, mon collègue n’est pas démotivé pour si peu, un sed plus tard et cette ignoble incompatibilité ne sera plus qu’à vague souvenir. Le script ne fonctionne toujours pas, il n’a pas installé les dépendances du scripts, il n’y avait pas pensé et rien ne lui indiquait que c’était le problème.

Il y a également certains points qui m’énervent, comme par exemple, le fait que certains scripts écrasent les fichiers d’entrée, d’autres créent les fichiers de sortie dans des sous-dossiers,… pas facile de s’y retrouver et on obtient assez rapidement une perte de fichier original lors d’une conversion si on ne fait pas attention. Je dois alors me rendre à l’évidence, ces scripts ne me conviennent pas vraiment. Je commence donc à écrire mes propres scripts et au fur et à mesure de leur mise en place, j’établis des règles de structure. Je ne suis pas un expert en code, mes scripts ne sont pas optimisés mais mes règles ont une logique qui me convient parfaitement (manquerait plus que ça…).

Mes choix techniques

Une fonction = un script

De nombreux scripts pour redimensionner des images ouvrent une boîte de dialogue pour sélectionner une dimension parmi une liste pré-établie. C’est très pratique mais ce n’est pas cette solution que je souhaite : Cette liste de dimensions je peux l’avoir directement sans passer par zenity (qui est la solution la plus couramment utilisée), il suffit que je clique directement sur le script correspondant au redimensionnement de mon choix. Ainsi s’il me manque une taille, il suffit que je copie-colle et modifie très légèrement un script, au passage cela m’évite un clic.

Un script compatible avec le shell

Les scripts sont très pratiques à utiliser depuis le navigateur de fichier mais ce n’est pas parce qu’ils sont commodes ainsi qu’ils ne doivent pas être fonctionnels dans le shell. Je n’utiliserai donc pas NAUTILUS_SCRIPT_SELECTED_FILE_PATHS ou son équivalent NEMO. Si le script est lancé depuis un terminal, les éventuels messages s’afficheront dans celui-ci, le fichier de sortie sera alors placé dans le dossier courant plutôt que dans le dossier du fichier d’entrée…

En cas d’erreur, on ne laisse pas l’utilisateur sans information

Des notifications si le format du fichier d’entrée n’est pas compatible avec la fonctionnalité, des notifications si une dépendance manque, des notifications si le nombre de fichiers d’entrée n’est pas adéquat,… Ces notifications doivent se faire quelque soit le système de l’utilisateur donc j’ai écrit une fonction dédiée. Pour vérifier les dépendances, de même c’est une fonction qui est utilisée.

Le type de fichier via mime-type

Beaucoup de scripts se contentent de récupérer les 3 dernières lettres du nom de fichier pour déterminer son type, d’autre un peu plus précautionneux récupèrent les caractères situés après le dernier point (${arg##*.}) ce qui évite déjà les problème de jpeg par exemple. Je préfère une solution à base de mimetype -bM "$arg" | cut -d "/" -f2 (ou f1 or sans cut selon le besoin…). Cela me semble plus sûr…

On écrase jamais le fichier d’entrée

J’ai choisi de toujours créer un fichier de sortie différent du fichier d’entrée pour éviter tout accident, toute perte de data. J’aurais pu faire le choix de procéder préalablement à un cp "$1" "$1~" mais pour l’instant ce n’est pas mon choix.

Des noms de scripts contenant des symboles pour simplifier la compréhension

Un million de fois je me suis demandé si je devais utiliser flip ou flop pour faire une symétrie axiale verticale. D’ailleurs une symétrie verticale c’est quand l’axe de symétrie est vertical ou quand le déplacement se fait du haut vers le bas ? Et puis (grâce au bépo), j’ai découvert qu’il y a pleins de caractères qui sont accessibles sur un clavier, par exemple altgr+shift+6 du pavé numérique permet d’obtenir "⇒". En mettant, de tels caractères dans les noms de scripts tout me semble alors plus clair :

scrennshot

Des noms de scripts contenant des variables

J’ai un script pour tourner les images de 90°. Si je veux celui qui permet de les tourner de -90° je trouve dommage de devoir copier-coller le script et de parcourir ce nouveau fichier à la recherche de la (ou les) variable(s) à retoucher. Dans le nom du script, il y a une variable (que je place entre crochet), si je veux le script qui tourne de -90° j’ai juste à copier-coller le script qui fait la rotation à 90° et à nommer cette copie comme il le faut. Je peux même faire un simple lien symbolique plutôt qu’une copie si cela me chante.

Utilisation de l’anglais uniquement

Les traductions demandent des contributeurs réguliers et un suivi continu. J’ai fait le choix de tout écrire en anglais et d’écrire des phrases les plus courtes et claires possibles pour les notifications. Avec mes compétences linguistiques dans la langue de Chèque-C’pire je suppose que les fautes vont bon train mais cela n’a pas d’importance puisque ces scripts ont une visibilité quasi nulle.

Y a plus qu’à…

J’ai décidé d’héberger mes scripts sur github (je voulais le faire sur un équivalent libre genre framagitlab mais quand j’ai vu que framasoft utilise github…). Du coup, j’apprends à utiliser git pour l’occasion, c’est sympa (mais pour l’instant je galère dès que je dois utiliser autre chose que add, commit, push ou pull). Je ne sais même pas comment gérer des branches, de multiples utilisateurs…

Pour l’instant mes scripts ne respectent pas tous mes propres règles car j’établis celles-ci au fur et à mesure des idées et de l’écriture mais c’est en bonne voie. Par exemple, pour le moment je n’ai pas de procédure pour vérifier si le fichier de sortie existe et incrémenter son nom, je n’ai pas non plus de vérification préalable des droits d’écriture… c’est en cours.

Si vous avez des idées, des remarques, des conseils, je suis preneur, n’hésitez pas à me dire ce que vous pensez de cette initiative.

Bon, déjà, première remarque : Ce texte était censé être un journal de présentation pas un roman…

  • # Moi j'aime bien

    Posté par  . Évalué à 5.

    Moi j'aime bien. Ça a le mérite d'être simple, à la fois à comprendre, à étendre et à créer.

    Petite suggestion : quelques fonctionnalités sont souvent réutilisées dans tes scripts et mériteraient d'être mise en commun dans un fichier à part puis "sourcer" par les autres. Je pense aux fonction 'notif', 'depend_check', les vérifications du nombre d'arguments, le "calcul" du nom du fichier de sortie, les évaluations du type mime et peut-être d'autres que j'aurais manqué.

    • [^] # Re: Moi j'aime bien

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

      J’y ai pensé en effet mais cela supprime la possibilité de ne prendre qu’un script simplement. C’est le même problème que pour les liens symboliques, cela supprime une fonctionnalité intéressante de ces scripts : l’extrême simplicité d’installation… Une fonction = un fichier à copier. Mais en effet, cela serait une évidence dans un contexte différent.

      • [^] # Re: Moi j'aime bien

        Posté par  . Évalué à 4.

        Tu peux peut être utiliser un préprocesseur. Tu garde une bibliothèque de fonctions que tu inclus par via une directive comme #include depend_check et tu as une étape de préprocesseur avant d'avoir tes scripts utilisables. Ça te simplifierait la maintenance tout en gardant ce coté self-contained de tes scripts.

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

        • [^] # Re: Moi j'aime bien

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

          Tu peux peut être utiliser un préprocesseur.

          Il vaut peut-être mieux utiliser une macro m4 pour ne pas à avoir à gérer les "invalid preprocessing directive" à chaque # en début de ligne.

          include(`depend_check')

          • [^] # Re: Moi j'aime bien

            Posté par  . Évalué à 3.

            Oui probablement, ce que j'aime bien avec la syntaxe # c'est justement qu'elle s'apparente à un commentaire, donc le code reste lisible est correctement coloré même avec l'étape de processing. Ensuite utiliser m4, cpp voir une tambouille perso c'est au choix :)

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

            • [^] # Re: Moi j'aime bien

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

              Par contre, je suppose que la solution que vous proposez vous semble évidente mais pour ma part, je ne pine rien à ce que vous proposez ici (techniquement parlant), si ce n’est que cela semble intéressant et que du coup je vais devoir à un moment ou un autre finir par chercher dans la doc pour approfondir… Vous êtes ici bien au-dessus de mes compétences. Mais en tout cas, merci.

              • [^] # Re: Moi j'aime bien

                Posté par  . Évalué à 3.

                Pas de problème ce n'est pas censé être inné. Un préprocesseur c'est un programme qui va prendre un fichier en entrée et sortir une version modifiée de ce fichier en sortie.

                L'idée ici serait d'avoir un fichier rotation_image.sh comme ça :

                #!/bin/bash

@include "ma_fonction"

# le code

ma_fonction "$arg"

# encore du code

                et un autre fichier ma_fonction.sh contenant :

                ma_fonction() {
    # le code de la fonction
}

                et d'avoir une commande qui permet de produire le fichier :

                #!/bin/bash

ma_fonction() {
    # le code de la fonction
}

# le code

ma_fonction "$arg"

# encore du code

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

                • [^] # Re: Moi j'aime bien

                  Posté par  . Évalué à 0.

                  Tu as un opérateur source qui fait exactement ce que fait ton @include en shell, sans avoir besoin de générer un fichier.

                  • [^] # Re: Moi j'aime bien

                    Posté par  . Évalué à 4.

                    Non, c'est ce dont il est question plus haut.

                    source (ou le .) fait ça de manière dynamique, c'est une commande du shell. Ici l'auteur veut que les scripts soient autosuffisant que la recopie d'un simple fichier soit suffisant sans avoir à récupérer les dépendances qui vont avec.

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

                    • [^] # Re: Moi j'aime bien

                      Posté par  . Évalué à 1.

                      Dans ce cas tu peux utiliser la même astuce que busybox

                      mafonction() {
}

mafonction "$(echo $0 | cut -f2 -d-)"

                      Ensuite tu fais un ln (ou cp) mafonction.sh mafonction-1, et un appel sur ce fichier (mafonction-1) appelera mafonction 1

                      • [^] # Re: Moi j'aime bien

                        Posté par  . Évalué à 3.

                        J'ai pas compris le rapport…

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

  • # N'empeche...

    Posté par  . Évalué à 10.

    Bon, déjà, première remarque : Ce texte était censé être un journal de présentation pas un roman…

    Il n'empeche que j'ai tout lu.

    Merci pour ce retour d'experience.

  • # Côôl !

    Posté par  . Évalué à 10.

    Eh ben, voilà une chose dont j'ignorais l’existence. Espérons que ce soit aussi le cas des développeurs GNOME sinon cette fonctionnalité ne risque pas de faire long feu.

    En attendant son éventuelle suppression, je vais réfléchir à comment en faire bon usage. Merci pour cette découverte.

    • [^] # Re: Côôl !

      Posté par  . Évalué à 1.

      oui c'est sympa effectivement, et le code est clair et bien écrit (de ce que je peux en voir).

      J'ai également des scripts un peu similaires (réduire taille d'image, conversion de pdf ou cbr en fichiers cbz par exemple), mais comme je n'utilise pas nautilus, du coup je fais tout en bash depuis la ligne de commande, comme ça je suis sûr que ça ne sera pas retiré par l'équipe de gnome, même s'il y a toujours le risque que le shell soit retiré vers 2021 dans GNU/systemdnux par Lennart.

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # Framasoft et github

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

    Petite correction sur

    je voulais le faire sur un équivalent libre genre framagitlab mais quand j’ai vu que framasoft utilise github…

    Oui, Framasoft a un compte github. C'était ce qu'on utilisait avant. Maintenant on a un Gitlab (https://git.framasoft.org) qui pousse aussi sur github pour faire miroir : il ne faut pas se leurrer, beaucoup de gens iront sur github avant de chercher si on a un gitlab dans un coin. Mais on pousse sur le Gitlab. Et il est ouvert à tous.

    AVANT DE VENIR RÂLER QUE MON URL NE FONCTIONNE PAS : on a un souci sur l'infra en ce moment (depuis dimanche 18 janvier) qui fait que notre gitlab n'est pas disponible. On va essayer de le remettre en route le plus vite possible, mais bon, on est surtout des bénévoles et le problème est cossu (problème de drbd qui déconne entre les nœuds du cluster ganeti, pour ceux à qui ça cause (d'ailleurs s'il y en a qui ont de l'expérience sur drbd, les avis sont les bienvenus.)). Et cette semaine, c'est l'avalanche de merde sur ma tronche, donc je vais attendre la semaine prochaine avant de revenir sur notre problème, parce qu'avec ma scoumoune actuelle, les disques risquent d'exploser (c'est pas que je sois particulièrement superstitieux, mais ça fait depuis dimanche que j'ai pas une journée sans emmerde : j'attends donc d'avoir un jour de répit pour me dire que la loi des séries me fout la paix).

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: Framasoft et github

      Posté par  . Évalué à 6.

      Ben en fait l'URL ne fonctionne pas.

      --> []

    • [^] # Re: Framasoft et github

      Posté par  . Évalué à 1. Dernière modification le 23 janvier 2015 à 10:26.

      Gitlab est super et gitlab.com propose des comptes gratuits pour un nombre illimité de projets publics ou privés.

      https://gitlab.com/

      Rapide comparaison avec github:

      • gitlab est un logiciel libre
      • github ne permet pas de comptes privés
      • github offre l'hébergement des github pages
      • gitlab a sa propre solution d'intégration continue gratuite depuis hier.

      ps: merci pour ces scripts, je me rue dessus !

  • # Git

    Posté par  . Évalué à 8.

    Du coup, j’apprends à utiliser git pour l’occasion, c’est sympa (mais pour l’instant je galère dès que je dois utiliser autre chose que add, commit, push ou pull). Je ne sais même pas comment gérer des branches, de multiples utilisateurs…

    Si tu veux en apprendre plus sur git, il y a le livre Pro Git, disponible en ebook gratuitement et sous licence (presque) libre. Il a été traduit en français : http://git-scm.com/book/fr/v2

    Git est une révolution quand on a commencé avec CVS. Son principal atout est de pouvoir gérer les branches de manière rapide et presque tout le temps sans douleur. Ce serait dommage de passer à côté.

  • # ROX-Filer

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

    Rox permet aussi très facilement ce genre de choses.
    Clic-droit sur un fichier et tu as une option « personnaliser le menu » qui t'ouvre un répertoire par exemple : ~/.config/rox.sourceforge.net/SendTo/.application_x-grisbi si c'était un fichier Grisbi, et là-dedans tu mets des liens vers des programmes (/usr/bin/grisbi par exemple) ou des scripts, en bref n'importe quel exécutable shell.

    Ce ne sont donc pas des scripts génériques à appliquer à n'importe quel fichier d'entrée, et dans lesquels tu analyse si tu as bien le bon type, mais directement des scripts adaptés au type de fichier.
    Bien sûr tu peux faire un répertoire SendTo/.image pour mettre des entrées pour toutes les images.

    Ce qui est intéressant c'est que tes scripts fonctionnent directement comme ça.
    Bon, sauf que je n'ai pas la commande « mimetype », j'ai modifié la ligne en remplaçant « mimetype -bM » par « file -bi », je ne sais pas ce qui est le plus portable, je suppose que la commande avec file est plus générique, je ne sais pas d'où vient la commande mimetype.
    Prend l'avis d'autres personnes, mais peut-être que pour avoir un script plus générique il vaudrait mieux utiliser « file -bi ».

    En tout cas, rox, pour le paramétrage par scripts et tout, c'est vraiment génial :)
    Déjà l'action par défaut se paramètre aussi aisément avec une commande, des arguments, tout ce que tu veux.
    Par exemple pour tout fichier de type "audio/" ma commande par défaut est « audacious -e "$@" », ça rajoute à la playlist d'audacious.
    Là aussi tu peux choisir entre audio/x-vorbis+ogg ou audio/. Par exemple utiliser audacious pour tout les fichiers audio, mais pour les audio/midi lancer Timidity, ou pour les audio/wav lancer audacity par exemple.

    En tout cas tes scripts sont bien parce que génériques et non liés à un environnement, alors je pense que je vais allègrement piocher dedans :)

    Yth.

    • [^] # Re: ROX-Filer

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

      je croyais que mimetype était une commande courante… bon je vais regarder ça, merci.

      Les fonctionnalités de ROX-filer dont tu parles ici me font penser au fonctionnement du gestionnaire de fichiers de elementary os.

      C’est un fonctionnement intéressant mais qui me semble comporter quelques lacunes (du moins, je n’ai pas vu comment faire), par exemple si j’ai 50 scripts pour les images comment les mettre dans un sous-menu.

      • [^] # Re: ROX-Filer

        Posté par  . Évalué à 2.

        je croyais que mimetype était une commande courante… bon je vais regarder ça, merci.

        Courante ne veux pas dire commune (pas dans le sens de la rareté, mais dans le sens ou tout le monde l'a). Sous un système libre, il est très peu probable que tout le monde ait les mêmes commandes, et c'est encore pire quand on parle de l'environnement d'un logiciel portable… je suis bien placé pour le savoir, je suis tombé plus d'une fois sur des bugs de logiciels/paquets dus à un système minimal*:

        Sinon, pour répondre à la question de l'auteur de ce fil, sous Debian, avec le paquet "command-not-found":
        ~$ mimetype
        The program 'mimetype' is currently not installed. To run 'mimetype' please ask your administrator to install the package 'libfile-mimeinfo-perl'
        mimetype: command not found

        *: dans l'ordre: install de Debian avec aucun outil coché, nettoyage des paquets non essentiels installés malgré tout (une bonne 30aine l'air de rien), désactivation de l'installation automatique des paquets recommandés, et enfin installation de ma sélection de logiciels… et par la suite, ça bouge régulièrement machine de dev oblige, avec parfois des purges manuelles du système. Je n'ai jamais plus de 1200 paquets installés sur une machine perso (à cause des libs de dev, surtout (mention spéciale pour la SDL d'ailleurs), sinon sur une machine «normalle» j'avoisine les 800).

        • [^] # Re: ROX-Filer

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

          du coup il faudra que je fasse plus de vérification de dépendances, ça ne coute pas grand chose de vérifier que tout est bien là… je verrai cela dès que j’aurai mieux optimisé le check de dépendances

      • [^] # Re: ROX-Filer

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

        Avec Rox, tu peux créer des sous-répertoires.
        Par exemple :
        ~/.config/rox.sourceforge.net/SendTo/.image/rotation/
        Dedans je met tes cinq scripts : [flip] ↕, [flop] ↔, rotate [90°] ↷, rotate [180°] ↻, rotate [-90°] ↶.
        Je modifie juste l'histoire du mimetype/file sans toucher à rien d'autre.
        Et j'ai dans mon menu un sous-menu rotation avec les cinq fonctions.

        Donc ça s'organise facilement aussi !

        Le seul point un petit peu dommage c'est que dans le menu clic-droit de base, tu as seulement les fonctions les plus précises, avec toutes les fonctions Rox normale du menu contextuel, donc par exemple celles dans SendTo/.image_svg+xml-compressed (ou j'ai mis simplement « decompress svgz→ svg »), mais pas celles de SendTo/.image/, ou même des génériques applicables à tout les fichiers directement dans SendTo/.
        Pour avoir le menu SendTo complet il faut faire shift-clic-droit, et là tu as toutes les fonctions SendTo, et uniquement elles, classées entre les générales (SendTo/), les semi-générales (SendTo/Image/) et les spécifiques (SendTo/image_png), avec des sous-menus partout où il faut.

        Yth.

    • [^] # Re: ROX-Filer

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

      Bon du coup je vais remplacer mimetype -bM "$input" | cut -d "/" -f2 par file --mime-type -b * | cut -d "/" -f2

      et tu m’as permis de découvrir file -z qui me permet de regarder dans les gzip pour vérifier qu’il s’agit bien d’un svgz. Merci

      • [^] # Re: ROX-Filer

        Posté par  . Évalué à 5.

        Danger ! Tu devrait au moins faire :

        file --mime-type -b -- * | cut -d "/" -f2

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

        • [^] # Re: ROX-Filer

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

          Pardon, j’ai mal copié ma commande je n’ai pas mis * mais "$input" bien sûr.

          • [^] # Re: ROX-Filer

            Posté par  . Évalué à 4.

            Ça ne change rien :

            # v='-lrt'
# ls "$v"
# ls -- "$v"

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

            • [^] # Re: ROX-Filer

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

              Ah, pardon. Merci pour l’astuce, j’en prend bonne note

            • [^] # Re: ROX-Filer

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

              Je constate l’intérêt de ce --, je le comprends, toutefois j’aurais aimé trouver des infos à son propos, j’ai beau tenter de googler, je ne trouve pas le mot clé qui convient…

              • [^] # Re: ROX-Filer

                Posté par  . Évalué à 4.

                Il faut chercher "shell double dash". C'est fait pour indiquer la fin des options.

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

  • # Composition

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

    par exemple altgr+shift+6 du pavé numérique permet d’obtenir "⇒"

    Perso je trouve plus facile à mémoriser altgr + = + >.

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Composition

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

      l’avantage du pavé num ici c’est qu’il est possible d’obtenir toutes les fleches : ↖↑↗←↔→↙↓↘↕ en altgr et ⇖⇑⇗⇐⇔⇒⇙⇓⇘⇕ en altgr+shift

      • [^] # Re: Composition

        Posté par  . Évalué à 2.

        En azerty j'ai aussi ces flèches de cette façon. Bon… par contre c'est pénible, il faut décaler les 2 mains… arg!

        • [^] # Re: Composition

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

          Je n’ai découvert cela que depuis que je suis en bépo, je pensais que c’était lié, merci pour la correction.

          Note d’ailleurs, je croyais également que l’accès aux lettres grecques αβγπλω… avec la touche morte µ était aussi uniquement possible en bépo mais la technique est aussi fonctionnelle en azerty, il suffit de suivre les instructions du site bépo.

          Mon pavé num est en Fn dans un clavier ergodox donc je n’ai pas à décaler mes doigts

          • [^] # Re: Composition

            Posté par  . Évalué à 2.

            un clavier ergodox

            Ça à l'air pratique: tu peux mettre l'assiette entre les 2 morceaux de clavier pour éviter que la pizza salisse le-dit clavier :D

            Plus sérieusement, c'est un clavier intéressant. Par contre j'ai toujours eu du mal avec la touche FN, probablement parce que je ne l'ai jamais, mais alors strictement jamais vue placée de façon intelligente.

  • # Bonjour et contribution

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

    Salut bonjour,

    Ça faisait longtemps … Je te propose si tu le souhaite un coup de main pour tes script.
    j'utilisais cela a l'époque ou file-roller n'existait pas encore … archiver unarchiver (et déjà l'emploi de file plutôt que mimetype….)

    si tu veux je suis à ta disposition …

    Nazeman

    • [^] # Re: Bonjour et contribution

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

      Je n’ai pas encore bien compris comment se passe les histoires de branches git, ni trouvé le courage de migrer vers un dépôt libre pour le moment mais toute bonnes volontés sont les bienvenues. Pour l’instant j’en suis vraiment au début du projet, je ne sais pas ce qui t’intéresserait ni comment être efficace mais je suis preneur !

      • [^] # Re: Bonjour et contribution

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

        Je viens de replonger dans tout ca …

        Je suis en train d'essayer de factoriser tout cela avec un seul fichier de fonction.
        Dès que j'ai un résultat viable je te l'envoie si cela t'interesse.

        Je pense que ca pourrais etre utile comme ca un seul fichier a modifier et raccourcir les script a leur plus petites fonctions …

        Redis moi stp.

Suivre le flux des commentaires

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