Dans une logique d’économie de mouvements (l’informatique n’a-t-elle pas pour but de faciliter la vie ? oui, bon, pas toujours…) voici une extension pour GIMP permettant le redimensionnement de la brosse dynamique.

Lorsque vous utilisez un outil de peinture (pinceau, crayon, gomme, clonage, flou/netteté, assombrir/éclaircir, etc.) vous devez régulièrement passer par la fenêtre des options pour modifier la taille de votre brosse. Au passage, remarquez que la partie haute de la réglette offre un redimensionnement brutal, alors que la partie basse permet d’être plus fin.

L’extension Dynamic brush resize ajoute une fonction permettant de redimensionner la brosse en déplaçant la souris.

Téléchargez la version pour votre système et extrayez le script dynamic_brush_resize.py dans le dossier plug-ins de votre profil GIMP. Pour trouver l’emplacement de votre profil allez dans Édition → Préférences comme expliqué dans cet article.

Démarrez GIMP (ou redémarrez-le s’il est déjà ouvert).

La fonction Dynamic brush resize (tablet) apparaît dans le menu Outils. Mais, l’usage d’un menu ne nous avance guère dans notre quête de réduction d’effort.

Il faut maintenant affecter un raccourci-clavier à cette fonction. Allez dans le menu Édition → Raccourcis-clavier. Dans le champ de recherche tapez « dynamic ». Cliquez sur la ligne correspondant à la fonction. Attention, si vous venez de l’utiliser, elle apparaît également sous la mention plug-in-recent ; il faut sélectionner la ligne correspondant au nom python-fu-dynamicBrushResizeTablet.

En cliquant sur la ligne GIMP vous demande une touche ou combinaison de touches. Tapez la touche correspondant au raccourci que vous souhaitez. Personnellement j’ai choisi la touche G.

Voyons maintenant comment utiliser cette fonction. Ouvrez une nouvelle image vierge (fond blanc) et prenez le pinceau. Tracez.

Pressez la touche G (relâchez-là ensuite) puis déplacez la souris vers la droite. La taille de la brosse augmente. Pressez à nouveau la touche G pour arrêter le processus. Tracez.

Pressez à nouveau la touche G et déplacez la souris vers la gauche. La taille de la brosse diminue. Pressez G pour arrêter et tracez.

Voici la manipulation en vidéo.

Téléchargez Dynamic brush resize.

Cet article GIMP : Redimensionnement de la brosse dynamique est apparu en premier sur Formation logiciel libre.

Original post of Dimitri Robert.Votez pour ce billet sur Planet Libre.

Cela fait déjà pas mal de temps que j’insiste dans mes articles sur le fait que l’utilisation de logiciel ou de code source sous licence libre n’était pas (ou plus) suffisant pour garantir à l’utilisateur le contrôle de son informatique. C’est sans parler également des problèmes d’exploitation de ses données personnelles à des fins commerciales. Cette dérive, nous la devons principalement au cloud computing ou informatique nuagique comme disent nos cousins québécois.

Les services de Google, de Facebook et bien d’autres services en ligne sont basés sur des logiciels libres. Cependant il s’agit d’un assemblage de composants certes libres, mais le liant et le résultat final n’est pas sous licence de logiciel libre. Ceci est rendu possible grâce à l’utilisation de composants sous licences dites « permissives ». Il s’agit la plupart du temps de licence Apache. La licence GPL ne permet pas ce genre de réalisations. Pourtant il s’agit dans les deux cas de logiciels libres.

Nous voilà aujourd’hui avec des montagnes de code ouvert et des utilisateurs toujours prisonniers de leur informatique. Ce n’est pas un échec direct du logiciel libre, bien que sa communauté en soit en partie responsable, c’est un succès de son dérivé qu’est l’open source.

Informatique de confiance

Dernièrement Laurent revenait sur son blog sur cette notion d’informatique de confiance. L’utilisateur de base n’est pas en mesure de vérifier le code source d’un programme qu’il utilise. Il ne peut pas s’assurer qu’il ne contient pas de cochonneries. De même pour un service en ligne, même si l’intégralité de son code source est disponible sous licence libre, je ne suis pas en mesure de vérifier que le code utilisé sur le serveur est bien le même.

Nous sommes obligés de faire confiance à ceux qui nous les mettent à disposition. Un fait qui dépasse la problématique du cloud computing et existe depuis les débuts du logiciel libre.

Pourquoi parler d’informatique de confiance plutôt que de logiciel libre ? La confiance me semble une notion moins ambiguë pour le commun des mortels que la notion de liberté. Évidement chacun à sa sensibilité et ne positionne pas le curseur au même endroit. Cependant, avec toutes les affaires Snowden, les problèmes de boîtes noires, le niveau de sensibilité à ces problématiques est en train d’évoluer et la question se pose bien plus en terme de confiance que de liberté.

Comment répondre à cette nouvelle attente ? Je répondrais avec des logiciels et des services de confiance. Ce n’est que de la sémantique, je joue peut-être sur les mots, mais une informatique de confiance impose d’aller au-delà du logiciel. Les logiciels libres sont nécessaires et indispensables pour une informatique de confiance… mais pas suffisant.

Ce qu’il faut en plus c’est une éthique et une transparence que ne proposeront jamais les GAFA, car c’est aller à l’encontre de leurs intérêts économiques. Oh bien sûr à l’occasion d’une fuite de mot de passe, d’une panne, ils déploieront des trésors de communication pour nous convaincre qu’ils ne sont pas si méchants que cela et qu’ils savent résister à la pression des gouvernements inquisiteurs.

La levée de boucliers des acteurs du numérique français face à la mise en place des boîtes noires est cependant un signe que cette problématique de la confiance est devenue importante pour tout le monde. Elle semble même devenir un frein au « business ».

Parler de logiciels libres ne suffit plus, il faut désormais pousser au premier rang une informatique de confiance. Une informatique qui ne peut passer pour le grand public que par des structures à la gouvernance ouverte et régie par un objectif d’intérêt général. Je pense évidement aux associations et fondations et à l’économie sociale et solidaire.

Cela n’exclut pas forcément les entreprises. Elles aussi peuvent si elles le souhaitent faire preuve d’ouverture et de transparence et obtenir la confiance de leurs clients. Certaines y arrivent sans utiliser de logiciels libres…

L’informatique devient une ressource dans nos sociétés aussi importante que l’eau ou l’électricité.  De plus en plus de personnes âgées ont du mal à remplir des procédures administratives, car elles nécessitent de passer par des portails web ou des échanges de mail. Ce n’est là que le début.

Le plus drôle c’est que pendant que je rédige ce billet, je reçois un emailling de la fondation Mozilla dans lequel il est question de confiance.

La confiance ne se fabrique pas. Elle se mérite.
Mozilla, la fondation à but non lucratif qui a élaboré votre navigateur, a de nouveau été reconnu comme l’une des entreprises en ligne les plus dignes de confiance par le Ponemon Institute. Mozilla n’est pas régie par des bénéfices ou des actionnaires. C’est vous, nos utilisateurs du monde entier, qui nous motivez. Vous et votre vie privée êtes au centre de tout ce que nous faisons. Nous ne le faisons pas pour récolter les honneurs. Nous le faisons pour vous permettre de garder le contrôle, pour que vous puissiez naviguer sans souci. Nous le faisons parce que personne d’autre ne le fera. Cela signifie que vous pouvez compter sur Firefox, créé avec une mission : c’est d’abord vous qui comptez. Vous avez confiance en Firefox, faites-le savoir !

L’open source est l’utilisation du logiciel libre dans une orientation business. L’informatique de confiance est une utilisation du logiciel libre qui doit prendre en compte les transformations de notre société liées au numérique. La question de la confiance dans le numérique se pose (enfin ?) comme dans bien d’autres domaines. Elle va se poser de plus en plus avec le développement des objets connectés. Le sujet est vaste et j’ai bien conscience de ne faire que l’effleurer ici.

La confiance est une question de critères qui peuvent varier d’un individu à un autre. Quels sont pour vous les critères indispensables pour accorder votre confiance à un logiciel ou à un service en ligne ou encore un individu ? Les commentaires vous sont ouverts !

Article original écrit par Philippe Scoffoni le 01/05/2015. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Original post of Philippe Scoffoni.Votez pour ce billet sur Planet Libre.

Bonjour,

Devant le manque de participants, il n'y aura pas de soirée à la MJC ce vendredi.

Je profite de la liste pour rappeler à tous qu'il y a d'autres moyens pour rester en contact en plus de la liste de diffusion.

Vous pouvez créer un compte sur le réseau Diaspora. Pour cela, G3L met à disposition un "pod". Voici un lien pour vous inscrire : https://pod.g3l.org/i/4107b5296437

Vous pouvez aussi vous connecter au canal #G3L sur IRC Freenode.

Enfin, pour ceux qui le souhaitent, vous pouvez disposer d'un compte sur le site g3l.org afin de publier des articles. Ceux-ci seront automatiquement repris sur le site http://planet-libre.org/

A bientôt

JP

Original post of G3L.Votez pour ce billet sur Planet Libre.

Carlos Soriano Sánchez, le mainteneur de Fichiers, vient de poster un billet de blog où il revient sur certains changements introduits dans Fichiers 3.16, et ce qui est prévu pour la prochaine version.

Il y explique également que certains changements controversés, sont surtout dû au faible nombre de personnes testant les versions de développement, et par conséquent, le faible nombre de retours utiles obtenus. Il faut donc malheureusement attendre la sortie de la version stable pour voir les gens réagir, ce qui interdit tout changement au niveau de l’interface. Les utilisateurs sont donc contraints de devoir attendre six mois de plus, et l’arrivée d’une nouvelle version.

Il aborde ensuite un problème souvent reproché aux développeurs GNOME, leur manque d’écoute des utilisateurs et de leurs suggestions. Il trouve cela injuste, en citant quelques exemples récents : la perturbante suppression du raccourci F5 pour rafraîchir le contenu d’un répertoire, le fait que le réglage du zoom n’était plus sauvegardé (alors qu’il ne l’avait jamais été), ou le souhait de pouvoir ouvrir plusieurs fichiers simultanément avec une autre application. Problèmes qui ont tous été corrigés.

Mais il est d’accord pour dire que le gros problème, c’est finalement le manque de communication. Les développeurs ont certains objectifs, qui nécessitent parfois de commencer par effectuer d’autres changements, et dont l’ensemble peut s’étaler sur plusieurs versions, avant de pouvoir être menés à bien. Et sans communication sur les raisons de tel ou tel changement, les utilisateurs ont parfois bien du mal à comprendre la direction prise par le projet.

Depuis peu, une feuille de route a été mise en place, qui donne un aperçu de ce qui est prévu. Les différentes maquettes sont également accessibles. Sans oublier la liste des bugs qu’il espère pouvoir corriger pour la prochaine version ou pour la prochaine révision de la version stable actuelle. Et pour finir, ceux dont il espère sincèrement pouvoir s’occuper, mais dont on ne sait pas encore pour quelle version :)

Il conclut son billet sur l’une des nouveautés de Fichiers 3.18, l’apparition d’une boîte de dialogue pour la création d’un nouveau dossier, ou pour le renommage des fichiers. L’avantage étant de pouvoir faire des retours à l’utilisateur, au fur et à mesure de sa frappe (fichier déjà existant sous ce nom, présence de caractères spéciaux qui rendraient le nom invalide…), plutôt que d’obtenir une fenêtre d’erreur au final, qui annulerait toute l’opération.

Tout en garantissant que ça n’augmente pas le nombre de frappes clavier ou de cliques souris nécessaires pour obtenir le même résultat qu’aujourd’hui, ça serait également plus simple à utiliser sur des écrans tactiles.

N’hésitez donc pas à faire des retours (courtois :) sur Bugzilla, si vous avez des remarques ou suggestions (éventuellement accompagnées de cas d’utilisation, d’images ou de comparaisons).

Original post of Okki.Votez pour ce billet sur Planet Libre.

Quand on utilise un système GNU/Linux ou BSD quotidiennement, même si on n'est pas un accro de la ligne de commande, on n'échappe pas à l'utilisation du terminal pour certaines tâches non graphiques. Le choix du shell, comme le choix d'une distribution est question de goût personnel : les deux principaux shell, BASH et ZSH ont chacun leurs supporters. Si vous utilisez un terminal occasionnellement (qui a dit sous la contrainte) il y a fort à parier que vous utilisez le shell proposé par la distribution, probablement BASH dans une configuration standard qui vous convient tout à fait. Néanmoins, il est intéressant de personnaliser la configuration de son shell pour se l'approprier. C'est fun à réaliser et cela donne envie de faire plus de choses depuis le terminal.

Bon si dans quelques mois, les annonces de sortie du nouveau KDE ou Gnome vous font ricaner, que vous ne jurez que par Awesome, Rxvt et Tmux, vous êtes au bout du chemin, peut-être un peu trop loin d'ailleurs et vos contacts IRC ont tous une forte pilosité ;-)

Le prompt PS1

Le prompt est l'invite répétée en début de ligne, entre chaque commande, un truc du genre bob@montux >. Le prompt est porté par la variable PS1 dans le fichier de config BASH de chaque utilisateur (~/.bashrc). En fonction des goûts là encore, le prompt peut être synthétique et court ou afficher le maximum d'informations et prendre une ligne entière. Le site Bashrcgenerator.com propose un générateur de prompt par drag and drop qui couvre une petite partie de ce qui est possible. On peut ajouter des codes ANSI pour coloriser certaines informations. La doc ArchLinux est exhaustive sur ces codes. Il ne faut pas oublier de réinitialiser la couleur en fin de prompt pour que ça ne coule pas sur le reste de la ligne avec un reset. je suis adepte des prompts concis :

White='\\e[0;37m'        # White
Red='\\e[0;31m'          # Red
Reset=$(tput sgr0)
PS1="\\[$White\\]\\u:\\[$Red\\]\\w\\[$White\\] \\$\\[$Reset\\] "

Pour des prompts plus sophistiqués, on peut utiliser des fonctions shell pour ajouter des informations dynamiques en fonction du contexte, les infos GIT dans le contexte d'un répertoire de source par exemple, la charge CPU, l'état de la batterie. Le projet LiquidPrompt en est un parfait exemple facile à configurer.

Les alias et les fonctions

les alias sont des substitutions de commandes. On peut les utiliser pour éviter de mémoriser des paramètres compliquées en définissant de nouvelles commandes :

alias la='ll -A'    # 'la' : voir les fichiers cachés
alias lk='ls -lSr'  # 'lk' : trier par taille

Ou bien on peut redéfinir le comportement d'une commande en créant un alias du même nom forçant des paramètres :

# forcer une demande de confirmation pour éviter les boulettes
alias rm='rm --interactive --verbose'
alias mv='mv --interactive --verbose'

Quant aux fonctions, elles permettent de définir des commandes en langage shell directement dans le fichier .bashrc. On peut facilement abuser de cette possibilité et alourdir le fichier avec des commandes qu'on utilise une fois l'an. Dans ce cas, il est préférable de les sortir et de créer des fichiers exécutables accessibles dans le PATH (/usr/local/bin au hasard).

Voici les deux fonctions que j'utilise assez régulièrement :

function bak() { cp "$1" "$1_`date +%Y-%m-%d_%H-%M-%S`" ; }

function extract()      # Handy Extract Program
{
    if [ -f $1 ] ; then
        case $1 in
            *.tar.bz2)   tar xvjf $1     ;;
            *.tar.gz)    tar xvzf $1     ;;
            *.bz2)       bunzip2 $1      ;;
            *.rar)       unrar x $1      ;;
            *.gz)        gunzip $1       ;;
            *.tar)       tar xvf $1      ;;
            *.tbz2)      tar xvjf $1     ;;
            *.tgz)       tar xvzf $1     ;;
            *.zip)       unzip $1        ;;
            *.Z)         uncompress $1   ;;
            *.7z)        7z x $1         ;;
            *)           echo "'$1' cannot be extracted via >extract<" ;;
        esac
    else
        echo "'$1' is not a valid file!"
    fi
}

Les couleurs de LS

dircolors est une commande qui permet d'afficher le résultat de la commande ls en couleur. La plupart des config bashrc testent si dircolors est présent et l'utilise en rajoutant --color à ls par le biais d'un... alias (bravo à ceux qui n'ont pas lâché). Généralement, on a une section de ce genre dans notre .bashrc :

# enable color support of ls
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
fi

Si vous avez une section de ce genre, vos commande ls sont déjà colorisées. Mais le choix des couleurs et le style est configurable en exportant une variable LS_COLORS. Son format est une liste séparée par des ':'. Chaque élément définit la couleur et l'effet d'un type de fichier ou d'une extension.

Les types de fichiers :

• no NORMAL, NORM Global default, although everything should be something
• fi FILE Normal file
• di DIR Directory
• ln SYMLINK, LINK, LNK Symbolic link. If you set this to ‘target’ instead of a numerical value, the color is as for the file pointed to.
• pi FIFO, PIPE Named pipe
• do DOOR Door
• bd BLOCK, BLK Block device
• cd CHAR, CHR Character device
• or ORPHAN Symbolic link pointing to a non-existent file
• so SOCK Socket
• su SETUID File that is setuid (u+s)
• sg SETGID File that is setgid (g+s)
• tw STICKY_OTHER_WRITABLE Directory that is sticky and other-writable (+t,o+w)
• ow OTHER_WRITABLE Directory that is other-writable (o+w) and not sticky
• st STICKY Directory with the sticky bit set (+t) and not other-writable
• ex EXEC Executable file (i.e. has ‘x’ set in permissions)
• mi MISSING Non-existent file pointed to by a symbolic link (visible when you type ls -l)
• lc LEFTCODE, LEFT Opening terminal code
• rc RIGHTCODE, RIGHT Closing terminal code
• ec ENDCODE, END Non-filename text
• *.extension Every file using this extension

les effets :

• 00 Default colour
• 01 Bold
• 04 Underlined
• 05 Flashing text
• 07 Reversetd
• 08 Concealed

Les couleurs :

• 30 Black
• 31 Red
• 32 Green
• 33 Orange
• 34 Blue
• 35 Purple
• 36 Cyan
• 37 Grey

les couleurs de fond :

• 40 Black background
• 41 Red background
• 42 Green background
• 43 Orange background
• 44 Blue background
• 45 Purple background
• 46 Cyan background
• 47 Grey background

Les couleurs suppplémentaires :

• 90 Dark grey
• 91 Light red
• 92 Light green
• 93 Yellow
• 94 Light blue
• 95 Light purple
• 96 Turquoise
• 97 White
• 100 Dark grey background
• 101 Light red background
• 102 Light green background
• 103 Yellow background
• 104 Light blue background
• 105 Light purple background
• 106 Turquoise background

Les couleurs par défaut de dircolors sont bien pensées mais je n'aime pas l'utilisation abusive de l'empâtement gras. Je définis donc la couleur bleue pour l'affichage des répertoire mais en style non gras, je mets par contre en gras les répertoire ouverts à tous les vents (avec les droits d'écriture sur le groupe other), et en rouge non gras les fichiers exécutables.

export LS_COLORS="di=00;34:ow=01;34:ex=00;31"

J'espère que ces quelques exemples donnent envie de plonger dans les arcanes du fichier .bashrc pour l'ajuster à sa sauce et utiliser un peu plus la ligne de commande. De plus en plus de monde conserve ses fichiers de configuration sur GIT pour avoir un référentiel rapidement installable sur ses systèmes. C'est une habitude à laquelle j'ai aussi succombé : j'ai un projet dotfiles sous GitHub.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.