hocwp a écrit 325 commentaires

C'est juste que je préfére celles-ci par defaut : http://hocwp.free.fr/temp/clfswm-pager.png

Ah! merci Xavier. J'aurai du rajouter "à ma connaissance" :)
Sinon au passage, je prépare une nouvelle version avec de plus belles couleurs pour le pager et une documentation automatique du code qui permettra de le prendre en main plus facilement (il y a déjà une documentation automatique pour les touches). Sinon la base est finie : à part d'éventuels bugs plus rien ne bouge (ce qui explique les dates du CVS).

Euh, non il n'est intégré à aucune distrib (j'en ferai peut-être un pour Archlinux).
D'un autre côté, il suffit d'extraire l'archive et de lancer
clisp load.lisp
dans le repertoire clfswm après avoir arrété le gestionnaire de fenêtres courant.

Je vais refaire un peu de pub mais bon...
Je suis parfaitement ravi du gestionnaire de fenêtres que j'utilise actuellement vu que je me le suis codé aux petits oignons (après avoir essayé pas mal de WM : larswm, fvwm, oroborus, sawfish, stumpwm, dwm...):

http://common-lisp.net/project/clfswm/

Il y a ici un gros gif animé pour voir à quoi il ressemble : http://common-lisp.net/project/clfswm/clfswm-3.gif
J'en avais déjà parlé ici : http://linuxfr.org/comments/831557.html#831557

Depuis le dernier commentaire c'est devenu un projet officiel sur Common-lisp.net.
Et pour m'amuser, j'ai rajouté dans le fichier de config un exemple pour simuler la circulation des fenêtres à la larswm, dwm ou wmii (5 lignes de lisp).

Voila, il faut aimer mettre les mains dans le lisp (et hop 99% d'utilisateurs potentiels perdus :) mais peut-être que ça peut servir à quelqu'un.

Oui et avec des projets comme tile, tk peut aussi avoir cette tête là :
http://tktable.sourceforge.net/tile/screenshots/pixmap.html

Tiens, au passage, c'est très pratique qu'il soit extensible en lisp comme ça on peut se rajouter des vies infinie et se rendre compte que certain niveaux sont infaisables (testage inside :)

Pour xbindkeys, le fait d'avoir un langage de script (scheme/guile) m'a permit de laisser les utilisateurs faire ce qu'ils veulent du programme sans ce prendre la tête à modifier le programme en C directement ou à étendre le parser par défaut (qui est déjà suffisamment compliqué comme ça, même si la syntaxe est très simple) ou de me demander à chaque fois de rajouter la fonction dont ils ont besoins.

Le programme en C est le squelette et le langage de script accède au fonctions de base par une API simplifiée (ajouter/enlever une touche, associer une touche à un programme externe ou une fonction en scheme).

Ça m'a évité de rajouter des patchs en quantité pour faire telle ou telle chose. Et ce qui devait être fait à coup de scripts bash et de programmes externes est devenu beaucoup plus simple et plus puissant grâce à un langage complet (le scheme) avec lequel on peut définir de nouvelle fonctions/variables, avoir des tests, des boucles...

Faire la même chose avec un système de plugins aurait été possible mais pas aussi simple : compilation du plugin vs écriture à chaud dans le fichier de conf (qui est relu automatiquement des qu'il est modifié -> tu sauvegarde le fichier de conf et les modifications sont prisent en compte instantanément).

Peut-être Abuse ? http://en.wikipedia.org/wiki/Abuse_(computer_game)

Je continu mon petit jeu débile : voila la version en Common Lisp

(let ((two 3))
    (defun my-two (stream char)
        (declare (ignore stream char))
        (setq two (- 5 two))
        two))

(set-macro-character #\2 #'my-two)

CL-USER> (+ 2 2)
5
CL-USER> 2
3
CL-USER> 2
2
CL-USER> 2
3

Et en C sous Windows ça donne quoi ? :-)

Tiens ça me fait penser à un petit test en Forth :

variable two 3 two !
: 2 ( -- n) 5 two @ - dup two ! ;

Qui permet de calculer 2+2=5
2 2 + . -> 5 :-)
2 . -> 2
2 . -> 3
2 . -> 2 ....

Au passage, je sais que ce genre de bidouille est faisable en Lisp, mais vous connaissez d'autres langages qui permettent de faire ce genre de truc inutile (juste pour le fun) ?

Ben, je bosse dans un lycée de Beauvais (60).
Et c'est vrai que c'est agréable de ne pas avoir de crack et de pouvoir échanger des CD avec les élèves en toute légalité. Mais je passe parfois pour un extra terrestre en disant que je n'est pas de windows à la maison.
Mais c'est vrai qu'il faut encore faire gaffe au matériel qu'on achète.

Tiens, tout pareil : je suis prof de Physique Appliquée dans un lycée de l'Oise.

Je m'intéresse à l'informatique depuis 1980 (ZX81 puis TO7...)
J'ai decouvert Linux en 1999 avec une RedHat et maintenant j'ai des Debian, Slackware, *BSD un peu partout.

Sinon, je programme pour m'amuser sur mon temps libre pour faire ce que je veux de mes ordis.
Ce qui me plait avec Linux et le libre plus généralement c'est qu'on a accès à tous les rouages de la machine : un rêve pour quelqu'un qui cherche à comprendre comment fonctionnent les choses. Rien n'est obscure. C'est cette philosophie du partage qui me semble vraiment importante.

Bon ben j'en remet une couche,

Dans clfswm(*), les groupes sont comme les fenêtres des wm classiques (dans le second mode ou avec le pager, on peut les déplacer, les redimensionner...) sauf qu'ils peuvent regrouper plusieurs fenêtres au même endroit (un Alt-Tab permet de circuler entre elle).
J'ai rajouté récemment une fonction qui permet de repartir toutes les fenêtres d'un groupe dans des groupes différents -> ça permet de simuler encore plus les windows managers classiques (chaque fenêtre est indépendante et pas forcement tillée).

En ce qui concerne l'environnement de dev, les groupes peuvent être tillés. J'ai rajouté aussi le mode à la larswm,dwm, wmii. La position où on veut mettre les autres fenêtres étant configurable (tillées en haut, à droite... avec la fenêtre principale au centre).
On peut même si on veut créer un bureau avec les groupes repartis de manière fixe et envoyer telle fenêtre dans tel groupe (style l'éditeur de texte va dans le groupe qui est en position (0,0)-(500, 800) dans le 2ème bureau...).

* http://common-lisp.net/project/clfswm/

Ah, ben c'est pour ça alors ! vim c'est du C, emacs du lisp. Un code en lisp étant 10 fois plus compact que l'équivalent en C on en conclue qu'emacs est 25 fois mieux que vim (et 125 fois mieux qu'elvis) :)
Hmm, m'en vais me cacher dans /dev/null...

Je suis tout à fait d'accord pour la compilation de la configuration. Je pensais partir sur cette base pour clfswm, mais je me suis rendu compte que les changements sont pénibles d'une machine à l'autre et que ça rend le suivit des version difficiles pour les utilisateurs. Un fichier de configuration avec un langage compréhensible est beaucoup plus efficace pour tout le monde. Ca évite d'aller fouiller dans le code à coup de grep pour refaire sa configuration à chaque changement de version.

Si j'ai bien compris, ce que tu appelles « groupe » est l'équivalent des cadres de ion3 : un rectangle de l'écran, qui affiche une seule fenêtre, mais qui en contient plusieurs (sous ion3, il y a une barre de titre qui fait des tabs quand il y a plusieurs fenetres).

Oui c'est exactement ça. Un groupe est un cadre qui peut contenir plusieurs fenêtres et que l'on peut placer où on veut à l'écran. Ils ne sont pas forcement tilés comme dans larswm, stumpw ou dwm. Ils peuvent se chevaucher si nécessaire. Et ils peuvent être agrandis ou déplacés en tenant compte des bords des autres groupes pour perdre le moins d'espace.
Par contre je n'ai pas mis de barre de titre pour ne pas perdre de place.

Est-ce que tu penses que c'est utilisable par quelqu'un qui ne connaît pas common-lisp ? (je connais l'Emacs-lisp, c'est pas si loin, mais ...)

Ben c'est une variante du Lisp donc la syntaxe est la même et il y a des différences mais la base est la même.

Pour l'instant, je n'arrive pas à l'installer. J'ai pas essayé très fort, et si je suis convaincu de l'utilité, je suis prêt à y passer du temps, mais j'avoue qu'apprendre tout ça si c'est juste pour évaluer la bête, c'est assez rebutant.

Le plus simple est d'avoir clisp [http://clisp.cons.org] de compilé avec clx et de faire un 'clisp /la/où/est/load.lisp' à partir d'un xterm seul sans autre gestionnaire de fenêtres.

Sinon j'ai mis des (mega) GIF animés pour donner une petite idée de la bête sur le site.

Ben c'est un fork dans le sens où je commençais à complètement changer le fonctionnement de stumpwm. Et au lieu d'avoir un fichier de configuration aussi gros que le code de stumpwm, ben j'ai écrit clfswm en gardant des idées de stumpwm.
D'ailleurs, j'encourage ceux que ça intéresse à forker de nouveau clfswm pour qu'il s'ajuste exactement à ce dont on a besoin.

Pour le problème du rafraîchissement, je l'ai quand j'utilise rox en parallèle mais pas en temps normal. Faut que je me repenche là dessus :)

Bon ben je vais faire de la pub mais temps pis...

Je suis parfaitement ravi de celui que j'utilise actuellement vu que je me le suis codé aux petits oignons
(après avoir essayé pas mal de WM : larswm, fvwm, oroborus, sawfish, stumpwm, ...):

http://hocwp.free.fr/clfswm/

Il a comme base tinywm et il s'inspire de stumpwm pour l'idée des cadres. Comme stumpwm il est écrit en Common Lisp (from scratch).

Sur le principe : Les fenêtres sont groupées par groupe et les groupes sont groupés par bureau. Les groupes sont la plupart du temps maximisé à l'écran.
Les groupes et les bureaux sont créés à la volée quand on en a besoin.
Il peut y avoir plusieurs fenêtres par groupe et une fenêtre peut apparaître dans plusieurs groupes ou bureaux
(c'est pratique pour avoir différentes vues des mêmes fenêtres).

Pour le gérer, il y a deux modes : Le mode principal avec très peu de raccourcis pour éviter les collisions avec les autres programmes.
Et un second mode ou le pager avec beaucoup plus de raccourcis qui permettent de gérer les groupes (fill, pack, resize...), les bureaux et les fenêtres.

Voila ce qu'on peut faire avec:

http://hocwp.free.fr/clfswm/keys.html

On peut le gérer rien qu'au clavier ou à la souris si on veut.
Et ceci est extensible (en Lisp) grâce au différents hooks ou pour créer de nouveaux raccourcis.

Les gros défauts : je l'ai codé pour moi, donc c'est vraiment pas sûr qu'il convienne à quelqu'un d'autre.
Nous devons être 3/4 à l'utiliser -> chez moi il est très stable, mais chez les autres... ?

Ben peut-être qu'ils sont toujours sur msdos 3 et qu'ils ne connaissent pas encore doskey...

Ça me rappelle les joies des premiers programmes en basic. Les programmes tapés tels quels depuis un bouquin sans trop comprendre tous les détails. Le lecteur de cassettes où le chargement foirait une fois sur deux parce qu'on avait bougé la bécane. Mais après que de parties de Monster
( http://enfr.explicatus.org/wiki/3D_Monster_Maze ).
Et il ne fallait surtout pas toucher à la RAM sous peine de faire planter le tout. Il est toujours dans le garage de mon père dans sa jolie boite en bois. Je ne sais pas s'il marche encore.

Pour ceux qui voudraient voir à quoi ça ressemblait :

http://rus.members.beeb.net/z81.html

avec la rom qui va bien :
ftp://ftp.nvg.ntnu.no/pub/sinclair/roms/zx81.rom

> Bref, si on veux un Linux Desktop, il est peut être temps de remettre en question certaines pratiques de temps à autres...

Boh, de toute façon je ne suis pas prêt pour le Desktop :)

Oh, non ce genre de script n'a rien à faire dans une distrib parce que
(1) je l'ai fais dans un but très precis pour un besoin très précis qui a très peu de chance d'être le même pour quelqu'un d'autre (mais il me convient parfaitement).
(2) Je ne l'ai pas polissé pour quelqu'un d'autre (c'est moi qui l'ai fait pour moi : je sais comment il marche et comment m'en servir, ce ne sera pas forcement le cas de quelqu'un d'autre et il faudra qu'il lise le script).
(3) Il est tout petit et pas du tout générique pour un autre usage et je n'ai pas l'intention d'ajouter des options pour d'autres besoins.
D'ailleurs d'autres l'ont déjà fait (cf burn, mp3burn, mp3cd entre autres) mais il me faudra de toutes façons scripter ces scripts pour arrivé au même resultat que mon vieux petit script.

Il s'agit effectivement de CD différents dont je planifie la gravure. Il suffit d'indiquer où ce trouve les répertoires à graver et la seule interaction par la suite est d'appuyer sur entrée après avoir changé le CD.
Et pour la jaquette ? C'est une vraie question, à l'époque où j'ai fait ces scripts je n'avais pas trouvé d'interface graphique qui permettaient de tout faire de maniere simple (c'est à dire avec le minimum d'interactions avec le logiciel) pour graver plusieurs CD d'affilé.

Et bien je fais de la place ou je deplace les fichiers ou je fais des liens ou je vais chercher un autre outil (K3b par exemple).
Et toi tu fais comment quand tu as 10 cd à graver d'affilé et que tu veux éditer la jaquette du cd en même temps ? Je n'est juste qu'à appuyer sur entrée entre 2 cds (celui-ci étant automatiquement éjecté/refermé et la jaquette imprimée).

Je ne cherche pas à me faire mousser, je dis juste que pour mon usage courant un script est suffisant et plus simple que toutes les interfaces graphiques que j'ai essayé. Je ne parle pas de ma soeur ou du copain, ils choisissent les outils qui leur conviennent (et c'est surement le cas de k3b).