Logiciel : La fin du gestionnaire de fenêtres Kahakai
Posté par Taku (page perso, ). Modéré le 08 juin 2004.
En effet, selon l'équipe, la partie du code source de Kahakai héritée de Waimea serait beaucoup trop désordonnée et "sale", et travailler sur le nettoyage de la source aurait découragé une bonne partie de l'équipe, qui s'est désormais dissoute.
![[en]](../images/en.png)
Site de Kahakai (1344 hits)-
Snapshot de Waimea (1139 hits)
-
Site de Spook (547 hits)
-
Site de Aegis (577 hits)
> Lire la dépêche (15 commentaires, moyenne: 2,1).
Vous avez demandé le commentaire #426930.
Run by 
Cette page a été générée par Templeet en 0.0911s (dont 0.0391 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
fork (fork (fork (...)))
Dites, comment vous vous expliquer la fréquence des forks dans le monde des WM ? J'ai presque l'impression qu'à chaque fois que quelqu'un veut ajouter une feature à un WM existant, il le fait dans un fork. Bon, c'est pas que ça me dérange, je m'en fous même, mais je trouve ça bizarre...
Dans le domaines des éditeurs de texte par exemple, on s'est concentré seulement sur quelques uns bien extensible, et quand quelqu'un veut une nouvelle feature (par exemple un mode pour un nouveau langage), il se le code au niveau utilisateur, sans forker. Mais là, tous ces WM, c'est un peu comme si on disait «Y'a un nouveau fork de vi, vachement mieux pour éditer du html. C'est juste dommage qu'il soit pas compatible avec le fork qui sert à éditer du C.»
Enfin bref, pourquoi tout le monde n'utilise pas sawfish ou fvwm.
Hmmm... en fait c'est peut-être un troll mon affaire là...
[+] [^]Re: fork (fork (fork (...)))
hs: la fonction "proclist" qu'on peut voir dans le menu, est elle propre à Kahakai ou est-c'dispo ailleurs
moué...
[^]Re: fork (fork (fork (...)))
A ce qu'il me semble, les "gros" tels que KDE ou GNOME fonctionnent sans le moindre fork jusqu'à présent et donc plus ou moins sur le modèle des "gros" éditeurs de textes que sont vi et emacs. Je ne sais pas ce qu'il en est pour les éditeurs de textes moins connus, mais je ne suis pas sûr que leur développement diffère grandement de celui des gestionnaire de fenêtres de cette envergure.
Sinon, personnellement, je n'ai pas trop cette impression que ce beau monde progresse par forks: cela fait à peu près deux ans et demi que j'utilise des Linux et que je m'informe sur le sujet et je ne me rappèle pas avoir entendu parler de beaucoup de forks dans le développement des WM... Par contre, au niveau des serveurs graphiques...
[^]Re: fork (fork (fork (...)))
AFAIK, KDE et GNOME ne sont pas des WMs
Pour ce qui est des forks, il suffit de regarder les blackbox/fluxbox/openbox/whitebox .. et consorts ....
[^]Re: fork (fork (fork (...)))
Les editeurs de textes ont aussi leur forks.
Voici une liste des clones de vi trouvee en 2 minutes avec google:
vim , elvis, vile, levee, jVi
De meme pour emacs:
gnu-emacs, xemacs, Zile, Efuns, ng, micro-emacs
Il y en a evidemment beaucoups d'autres.
En general, l'histoire est la meme pour les WMs et les editeurs:
(1) Un gars decide que l'original est 'bloated'
(2) Fork! On va faire une version 'light'! c'est promis
(3) Code , code, code, nouvelle fonctionnalites, code , code ...
(4) Un gars decide que le 'fork' est 'bloated'
(5) Refork! On va faire une version 'light'! c'est promis
(7) Code Code Code ...
(8) ...
[^]Re: fork (fork (fork (...)))
J'ai l'impression que c'est ce qui va se passer avec Epiphany...
[^]Re: fork (fork (fork (...)))
Voici une liste des clones de vi trouvee en 2 minutes avec google
Ne pas confondre clones et forks.
(enfin, je dis pas qu'il n'y a pas de forks dans ce que tu listes, mais en tout cas il y a pas mal de simples clones)
[^]Re: fork (fork (fork (...)))
Bah les WM fournis par KDE et Gnome (qui, rappelons le, ne sont eux pas des WM), c'est un cas un peu particulier : que ce soit KWin ou Metacity, aucun ne présentent un réel intérêt en soit, sinon d'être le machin par défaut de l'environnement de bureau. Alors bien sûr, eux, les forker, c'est leur virer leur seul intérêt (oups, je suis un peu médisant peut-être), c'est voué à l'échec.
Je pensais plus là aux WM "indépendants". Prends par exemples les dérivés de blackbox (fluxbox, openbox, waimea, etc.), ou ceux de fvwm, ou pire encore ceux de 9wm (qui doivent bien être une vingtaine, si on compte les forks du fork aewm). Regarde cette page, tu verras, c'est un vrai un clapier :
http://xwinman.org/others.html(...)
Alors bien sûr c'est pas une loi universelle, et il y a des WM indépendants qui sont sans descendance (exemple au pif : icewm).
Mais bon quand même, ça ne m'ôte pas l'idée que globalement on fork dans ce monde là plus qu'ailleurs. Plus par exemple que chez les éditeurs de texte. Ok, y'a Xemacs qui a forké d'emacs, ou quelques autres dans le genre, mais je ne connais pas de smala à l'échelle de celles des WM.
[^]Re: fork (fork (fork (...)))
Les WM légers sont des programmes assez simples à comprendre.
Il est donc assez facile de modifier le code pour obtenir de nouvelles
fonctions ou pour faire varier l'interface en fonction de ce que
l'on recherche.
Si au lieu de forker on ajoute les fonctions voulues au WM qui
à servi de base celui devient moin léger et plus difficile à configurer.
On a donc ici l'apparition de logiciels que je nommerai ainsi :
"Configure It In The Code"
merci à l'open source !