hocwp a écrit 331 commentaires

> - un WM qui offre des fonctionnalité pour améliorer ma productivité (notion de frame, de groupe, fixé/flottant, full-screen, contrôle sans souris...)
Ok c'est ce que fait clfswm.

> - un WM qui permette d'accéder à toutes ces fonctionnalité y compris avec la souris (pour les jours où ma mémoire flanche, ou pour les actions peu courantes)
Tout est faisable à la souris dans le second mode par contre comme il n'y a pas de décoration il faut faire des alt+bouton.

> - un WM esthétique (qui s'intègre bien dans mon bureau Gnome)
Là ce n'est pas encore possible. Mais j'ai commencé à suivre les recommandations de Net WM (mais ce n'est pas une priorité).

> - un WM qui se configure "automatiquement" (il faut qu'il mémorise les groupes que je fait, qu'il se souvienne que j'aime avoir Emacs en plein écran, sans que j'ai à ouvrir un éditeur texte pour programmer dans un langage de script barbare).
Ca ce n'est pas très dur à rajouter vu que l'arbre des bureaux est connu. Il suffit de sauver la variable *workspace-list* de manière compréhensible à la fin de la session. Mais on peut déjà créer au demarrage un groupe dans tel bureau avec une géometrie donnée dans lequel on lance telle application.

Le principe de clfswm est que toutes les fenêtres sont maximisées à l'ecran (c'est le cas de la majorité des applications que j'utilise). Et si on veut des fenêtres plus petites, il suffit de les retailler pour les mettre où on veut (exemple : Le Gimp).

C'est effectivement le principe de clfswm sans le côté automatique. Les groupes peuvent être manipulés à la souris ou au clavier pour se placer sans laisser de place perdue.
Cette approche me semble plus souple qu'avec des gestionnaires comme AWESOME mais ça demande un tout petit peu plus de travail pour placer les fenêtres comme on le veut.
D'ailleurs on peut programmer le comportement que l'on veut. Je donne l'exemple d'un placement à la larswm qui est très facile à simuler.
(voir le fichier de configuration en exemple : http://common-lisp.net/cgi-bin/viewcvs.cgi/*checkout*/clfswm(...) )

Pour le placement et le redimensionnement il ne faut pas perdre de vue que le gestionnaire de fenêtre gère plusieurs fenêtres dans le même groupe. La gestion d'une fenêtre seule dans sont groupe est fluide (en tout cas je ne vois pas de différence avec dwm par exemple). Mais c'est vrai que je peut retravailler ce point en cachant les fenêtres non visibles.
Pour les couleurs j'ai fais de mon mieux, les couleurs précédentes du pager me semblant encore pires :)
Et pour la font, j'en ai mis une par défaut présente sur tous les systèmes mais ça reste configurable bien évidement (faut que je regarde se que mettent les autres par défaut).

Je ne connais pas clusterssh. Par contre il n'y a pas de notion de fenêtre flotante dans clfswm. Une fenêtre appartient à un ou plusieurs groupes et c'est le groupe qui est redimensionnable.

Pour ouvrir plusieurs fenêtres d'un coup clfswm propose une fonction qui permet d'ouvrir la prochaine fenêtre dans un nouveau bureau et les autres fenêtres dans de nouveaux groupes. On obtient un groupe par fenêtre dans un nouveau bureau. Après il ne reste plus qu'à tilé ce bureau par exemple. C'est ce que j'utilise quand j'ai besoin de suivre en même temps les logs de plusieurs programmes lancés automatiquement.

Ah, oui c'est vrai que c'est tout sauf sexy si on le compare à Compiz vu que le but est de ne pas voir le gestionnaire de fenêtre.
Comparé aux autres wm, il me semble un peut plus souple que ratpoison/stumpwm. Il reprend le principe des cadres de ion3 sans afficher les onglets. Et il gère un peu moins les fenêtres que wmii, même si se mode de fonctionnement reste faisable (d'ailleurs c'est ce qu'essai de montrer la video).
Et au niveau ergonomie il me convient, normal non ? :)

Pour appuyer tes dires on peut définir la fonction 'eval' du lisp codé en lisp à partir de seulement 7 opérateurs : http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp
Ce qui est relativement simple. Par contre le Common Lisp ne sera pas qualifié de simple si on compte les 978 symbôles[*] (fonctions, macros ou variables) définis de bases et sans compter, comme tu le dis, les mots clé de la macro loop... Mais le point de départ est extremement simple.
[*] http://www.lisp.org/HyperSpec/FrontMatter/Symbol-Index.html

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...