hocwp a écrit 331 commentaires

D'où l'intérêt de mettre un mot de passe dans le bios et d'interdire le boot sur autre chose que le disque principal (pour le pb de Linux en tout cas).

Après avoir écrit ça, ils n'ont plus le droit de quitter la boite :)

Oui et si tu obtiens ça, c'est que tu t'es gouré quelque part...
http://upload.wikimedia.org/wikipedia/commons/6/6e/Noeud_de_(...)

Désolé -----> [ ]

Mais c'est que ça marche en plus, je croyais que c'était une blague...

C'est le clavier utilisé par Chuck Moore (l'inventeur du Forth) pour son OS/Langage (ColorForth) : quitte à simplifier les choses, il a aussi simplifier la gestion du clavier. Il y a plus d'infos ici :
http://www.ultratechnology.com/editor/editor.htm

http://www.colorforth.com/keys.html M'enfin c'est pas encore pour mouler ici... :-)
( http://www.colorforth.com/cf.html )

Tout d'abord, merci beaucoup à toutes l'équipe de LinuxFR pour cette récompense !
C'est moi qui ai choisi le livre sur squeak et d'après ce que j'ai commencé à lire il répond exactement à mes attentes.
Je ne connais ni le smalltalk ni squeak et vu le sommaire et les captures d'écrans le livre aborde beaucoup de notions de manière claire. J'ai en particulier hâte de découvrir les squeaklets (http://wiki.squeak.org/squeak/1865).
Je pense que c'est un très bon livre pour ouvrir de nouveaux horizons et voir ce qui se fait chez les voisins.

Est-ce qu'il gère aussi l'appui sur plusieurs touches, du genre Ctrl+Alt+une lettre ? (je suppose que oui)
Oui, c'est la moindre des choses. Il gère aussi Ctrl+Alt+Bouton de la souris.

Même les touches non détectées par xev ? (je suppose que non)
Non, xbindkeys est en partie basé sur xev. Donc si xev ne détecte pas une touche, xbindkeys non plus.

Par rapport à hotkeys (que je ne connais pas beaucoup), xbindkeys n'est pas lié à un clavier particulier. Il ne se limite pas aux touches multimédia et les touches peuvent être déclarées par leur keycode ou leur keysym (c'est peut-être le cas pour hotkeys).Le fichier de configuration est soit très simple (une ligne pour la commande à lancer, une ligne pour la combinaison de touches), soit du Scheme.
La version en Scheme permet de faire des choses rigolotes de manière simple. Par exemple l'appui court/long. Appui de moins de 0,5s : lance un xterm. Appui de plus de 0,5s : lance un navigateur web.

Bon ben c'est parti. La suite ici : https://savannah.nongnu.org/projects/xbindkeys/

J'ai fais une demande de projet sur savannah.org. xbindkeys va sûrement continuer sa vie là-bas.

Oui, un tas de wm le font mais des que tu t'éloignes des sentiers battus ce n'est pas forcement le cas (par exemple tinywm, evilwm, oroborus, larswm...). Et maintenant Uzbl qui propose d'externaliser la gestion des touches. De plus xbindkeys est scriptable, on peut lui faire faire des choses qui ne sont pas prévues à la base (combinaisons de touches, double appuis...).

Wow, ben merci pour vos commentaires :)
En fait tout le problème est dans ce que tu dis genma : si les journées faisaient 48 heures, ce serait avec plaisir que je continuerai à répondre à chaque mail (je suis quand même le mieux placé pour savoir comment fonctionne xbindkeys). Mais la liste de ceux auxquels je n'ai pas répondu commence à augmenter et comme je n'utilise plus xbindkeys, les choses risquent de s'aggraver.
En fais il n'y a plus beaucoup de bug découvert dans xbindkeys. Et j'oriente très souvent ceux qui veulent de nouvelles améliorations vers des scripts Shell ou mieux du Scheme si ce qu'ils demandent est vraiment tordu.
Je ne laisse pas xbindkeys à l'abandon, c'est juste que je commence à prendre mes distances avec le service après vente au quotidien.
Et donc si quelqu'un a la volonté de prendre le relais, ce sera avec plaisir que je donnerai un coup de main pour le mettre sur les rails.

Je suis tout à fait d'accord avec toi. Tout dépend à quel niveau on se place. Perso, je suis très satisfait d'avoir fait des mans et de gagner énormément de temps sur ce genre de manipulation. Après si ta grand mère préfère perdre son temps parce que la souris est plus ergonomique (dans le sens où elle permet de faire plus de tests puisque tous les choix sont montrés) c'est son choix. Mais bon si comme dit plus bas le split et le cat sont cachés par un joli bouton accessible avec la souris tout le monde sera content (même si l'interface risque de se compliquer).
J'ai juste réagi parce que faire au moins 35 clics pour un fichier coupé en plusieurs morceau semblait compliqué et long à faire à l'auteur d'origine alors que ce n'est vraiment pas un problème avec les bons outils.

Je ne sais pas si elles courent beaucoup les rues mais en tout cas elles trouvent ça vachement plus pratique que de faire plein de clic clic.

Tiens, merci Ploum de relayer l'information à un niveau supérieur. Et au passage, je vous invite à découvrir ces excellents artistes : en plus d'avoir des propos très intéressants leur musique est vraiment très bonne ('fin pour ceux qui aiment l'électronique et les paysages variés).

Regarde ce qu'en pense Binary Mind par exemple :
http://www.jamendo.com/fr/artist/binary.mind
http://www.binarymind.org/ recherche 'Non à HADOPI'
http://www.binarymind.org/index.php?option=com_content&t(...)

Bien sûr que je l'ai lu. C'est juste que tu aurais pu ajouter quelques lignes dans ton commentaire expliquant pourquoi Perl, Ruby... pouvaient aller se rhabiller plutôt que de balancer une affirmation comme cela.
D'ailleurs la description dit bien que «BUSH scripts are slower to develop than Python programs but are easier to maintain over the lifetime of a project.» Donc si on veut faire quelque chose rapidement BUSH semble moins adapté que le Python (ou le Ruby puisqu'il reprend la même phrase).

Tu peux argumenter ?

Tout à fait, c'est ce que j'ai fais avec un portable à 133 MHz 32 Mo de ram et ça marche niquel (au moins pour se connecter à une machine plus puissante). Sur la machine, Links en mode graphique est parfait. Sinon, firefox lancé sur une machine plus puissante passe très bien.

Ben tu peux enfin te passer de la pédale sous le pied droit. Par contre il faut toujours celle sous le pied gauche : pas assez de boutons sur la souris....

Je vais casser mon propre outil, mais ce n'est pas la peine d'utiliser xbindkeys pour ce genre de chose. Xmodmap est plus adapté. Il suffit de rajouter un truc du genre dans son ~/.Xmodmap :
! Make Caps Lock be Ctrl instead
remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L
Sinon, perso je l'ai remappé pour faire en sorte qu'il simule un click du milieu de la souris.
remove Lock = Caps_Lock
keysym Caps_Lock = Pointer_Button2 Pointer_EnableKeys

Roh, toi tu as déjà fait du lisp ! Ton code se compile sans problème. Même pas d'erreur de parenthèses :)
CL-USER> (defmacro moi (&rest x) (print x) nil)
CL-USER> (defmacro je (&rest x) (print x) nil)
CL-USER> (moi (aussi (j'ai (un) (trouble)) (du)) (langage)) (je (parle) (en (lisp)))
((aussi (j 'ai (un) (trouble)) (du)) (langage))
((parle) (en (lisp)))

Pour la seconde partie, tu peux utliser Xmacroplay, Xreplay ou movemouse par exemple.

http://xmacro.sourceforge.net/
http://www.floc.net/xreplay/
http://hocwp.free.fr/movemouse.html

Pour la première partie, tu peux faire un petit programme qui fait un XGrabPointer.
Si ça t'intéresse, je viens de tester une version modifiée de movemouse qui fait ce que tu demande en un seul programme.

PS1='$PWD '
Ce qui évite d'évaluer $PWD au chargement du .bashrc.

L'équivallent de save-lisp [1] n'existe pas en python ?

Peut-être peux tu découper ton programme en deux. Une partie qui fait l'initialisation que tu charge en premier.
Puis la partie que tu débogues dans un autre fichier que tu recharges depuis le prompt.
Une session donnerai un truc du genre :

$ python -i longue_initialisation.py
>>> execfile("la_partie_test.py")
...
>>> execfile("la_partie_test.py")
...

Sinon, il y a sûrement un moyen plus direct de faire quelque chose comme Slime [2] depuis un éditeur.

[1] http://common-lisp.net/project/cmucl/doc/cmu-user/extensions(...)
[2] http://common-lisp.net/project/slime/