Fluxbox [1] est un gestionnaire de fenêtres pour le système X Window. Il est distribué sous licence MIT et est basé sur le code de Blackbox version 0.61.1. (source wikipédia [2]).
La version 0.9.15 de la branche dites de développement est sortie ce matin (tôt). Cette version n'apporte pas grand chose de nouveau, des bugs fixes quelques nouvelles directives de configuration et c'est tout.
La manière de "mettre" son fond d'écran a *encore* changé, je l'expliquerais ici [3] (je reposterais l'url exact lorsque ça sera écris).
Pour plus de détails consulter le changelog [4] ou les release notes [5]
[1] : http://fluxbox.org
[2] : http://fr.wikipedia.org/wiki/Fluxbox
[3] : http://fluxbox-fr.sysif.net/
[4] : http://fluxbox.org/version-0.9.php
[5] : http://fluxbox.org/changelog.php
[6] : http://svn.berlios.de/viewcvs/fluxbox/trunk/ChangeLog?rev=42(...)
PS : au vu du changelog [6] de la prochaine version (ie 0.9.16) il semblerait qu'on est droit au "retour de la vengeance" des 'tabs' (onglets) externes.
Journal Fluxbox 0.9.15
20
mar.
2006
# À quand une version stable ?
Posté par Zorro (site web personnel) . Évalué à 6.
Des fois, je trouve que la modestie extrême, ça frile l'immobilisme, alors que le projet est bien vivant, et excellent, même ! Sérieux, avec la moitié de leur travail, un éditeur commercial en serait au moins à la version 10 ! Faut pas prendre les mauvais tics non plus, certes, mais releasez, quoi, releasez !
[^] # Re: À quand une version stable ?
Posté par jaroug (site web personnel) . Évalué à 3.
Pour avoir poser la question, on m'a répondu que c'est le prochain objectif (quand ca sera près), que la version dev comporte encore pas mal de bug et que la documentation - qui est à la limite de la catastrophe - doit être revue.
[^] # Re: À quand une version stable ?
Posté par GCN (site web personnel) . Évalué à 3.
Si le numéro de version était un quelconque indicateur de la qualité du logiciel on le saurait depuis belle lurette. Les exemples de softs possèdant des numéros de version < 1 ne manquent pas. Je crois qu'il ne faut vraiment pas s'arrêter à cela.
[^] # Re: À quand une version stable ?
Posté par Jerome Herman . Évalué à 7.
Parceque fluxbox n'est pas stable. En informatique les dinosaures qui font la différence entre un hacker et un cracker font aussi la différence entre un logiciel fiable et un logiciel stable.
Un logiciel fiable est un logiciel qui fonctionne et fournit toujours le même résultat en réponse aux mêmes saisies. Fluxbox est un logiciel fiable.
Un logiciel stable est une version de logiciel qui est compatible au niveau API et/ou ABI avec les versions similaires de ce logiciel.
Par exemple si l'application en version 1.0.0 fait les choses d'une certaine façon, et que les bibliothèques de la version 1.0.0 compilent d'une certaine manière, on s'attend à ce que celà soit vrai au minimum pour la 1.0.1 et de préférence aussi pour la 1.1.0 (sauf correctuion de bug majeure). C'est ce que l'on apelle la stabilité logiciel. Ce qui est stable ce n'est pas le fonctionnement du logiciel, mais la façon dont il fonctionne.
A l'inverse Fluxbox change assez fréquamment son fonctionnement interne, soit pour coller au plus prèt aux standards freedesktop, soit pour utiliser les bibliothèques enlightenment (par exemple).
Le numéro de version en 0.9x sert donc à dire aux dévelloppeurs qui voudraient construire des applications par dessus fluxbox "attention, on risque de changer notre code plusieurs fois vous risquez donc de devoir recoder votre programme à chaque version."
[^] # Re: À quand une version stable ?
Posté par Zorro (site web personnel) . Évalué à 2.
Bon, ben alors, bravo aux équipes de Fluxbox pour la fiabilité de leur logiciel ! Et bonne continuation pour la stabilité, alors. (mais est-ce qu'il faut pas un jour se dire, c'est bon, on touche plus aux changements internes, et on dit que cette version est stable ? Quand est-ce qu'on décide ça ?)
[^] # Re: À quand une version stable ?
Posté par Jerome Herman . Évalué à 2.
C'est ce qu'on appelle le "Freeze". C'est le moment ou l'on décide que l'on ne fait plus que debug et que l'on ne touche plus aux interfaces.
Ca se passe généralement en fin de béta avant le cycle des releases candidates.
# Comme promis ...
Posté par jaroug (site web personnel) . Évalué à 3.
[^] # Re: Comme promis ...
Posté par hiphopmomo . Évalué à 1.
Difficile de faire plus simple quoi.
et pour changer le theme par defaut faut recompiler le kernel et fluxbox apres les avoir patche ou ils ont prevu un systeme de configuration utilisable par un humain normalement constitue?
desole pour les sarcasmes, mais la...
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Désolé mais le tout graphique avec du gconf en variable globale... c'est bien un peu mais des choses simples, c'est bien aussi.
[^] # Re: Comme promis ...
Posté par Thomas Douillard . Évalué à 2.
C'est bien tenté le troll gconf mais ça a un peu rien à voir : tu peux très bien faire une interface qui génère un fichier de conf tout ce qu'il y a de plus classique.
Enfin, sur les variables globales, je vois pas ce qu'il y a de plus global dans gconf que dans un fichier de config. Au pire, si tu veux plusieurs config possibles, des solutions avec gconf : mettre les clés ailleurs dans l'arborescence, et spécifier au logiciel ou il doit aller les chercher (équivalent d'avoir plusieurs fichiers de config alternatifs), permettre de lancer plusieurs instances de gconf, ...
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Si ils utilisent un bureau a distance via xvnc, tu peux leur préparer un bureau bien configuré sous icewm (comme ca ils ne sont pas trop perdus) et t'as gagné un paquet de ressources.
Avoir un utilitaire graphique qui t'aide a paramétrer, pourquoi pas. Mais faut pas non plus en faire une condition éliminatoire.
Je suis d'accord que ma phrase sur gconf était un peu hors sujet. J'ai deja pas mal posté sur gconf et je maintiens que ce truc n'est pas bon et que c'est un equivalent des variables globales. D'ailleurs, il y a un daemon gcond qui tourne en permanence (meme que parfois, ce co. survie a une fermeture de sessions...).
[^] # Re: Comme promis ...
Posté par Thomas Douillard . Évalué à 2.
Sinon, pour l'histoire des variables globales, j'attends toujours un argument qui me montre en quoi c'est plus global qu'un fichier de conf ;)
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.
Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)
Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.
Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...
[^] # Re: Comme promis ...
Posté par Thomas Douillard . Évalué à 2.
C'est AMHA juste une histoire des gestion d'événement, qu'un logiciel qui utilise gconf n'a pas forcément à utiliser : avec gconf, on doit pouvoir garder l'ancien comportement si on veut. Quand à savoir si c'est une mauvaise idée, ça m'a l'air très subjectif comme avis ;). Perso je pense que ça peut être bien pratique.
Sur la communication entre les processus : en pratique, le partage de paramètres (pas de données, en l'occurence) peut se justifier. C'est parfois agacant de devoir mettre en oeuvre des usines à gaz rien que pour pouvoir changer un pauvre paramètre dans deux processus, ce qui peut être un besoin, en pratique : quand tu changes ta config, tu n'as pas forcément envie de relancer tous tes logiciels, avec tout ce que ça implique.
Sur le D-BUS : AMHA gconf doit l'utiliser ... gconf gère des paramètres, comme une lib dynamique pourrait le faire, certe, mais à aussi plus de fonctionnalités. Si tu mettais en oeuvre un autre programme pour gérer aussi des paramètres, mais permettre de les échanger, et si tu voulais partager des paramètres entre plusieurs programmes, il faudrait faire communiquer gconf avec cet autre programme, ce qui est à priori déja le cas ...
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est vrai que c'est pratique mais avec du recul, c'est pratique pendant combien de temps ? Combien coute de faire des "restart" ? Au bilan, tu acceptes de diminuer ta sécurité pour un problème annexe, qui ne peux pas être, a ma connaissance, dé-activé.
Sinon, nous sommes d'accord, gconf en fait bien plus que ce pour quoi il est appeller : les fichiers de configuration.
Le propre d'UNIX est la séparation des taches. A cause de ce gconf qui en fait trop, gimp n'utilise pas gconf.
Moi, ca me gonfle qu'ekiga utilise gconf pour ces parametres (/A priori/, il ne partage rien avec les autres). Ca m'oblige a avoir un daemon gconfd qui tourne.
Idem, si je fais mon propre programme. Je ne veux pas forcement avoir un daemon gconfd qui soit associé a mon programme. D'ailleurs, pour mes fichiers de configuration, j'utilise le format YAML qui est très simple et répond parfaitement au cahier des charges.
Bref, j'aime beaucoup de programmes fait avec les librairies gtk et gnome mais je n'ai pas envie d'avoir toute l'artillerie de gnome derrière pour un simple problème de configuration de mes applications (remarque, c'est pareil avec les application kde). Je ne veux pas être enfermer a choisir soit les applications gnome ou les applications kde. Je veux pouvoir piocher et utiliser les applications qui me plaisent. Bref, la base gnome a un peu trop tendance a t'enfermer dans son environnement.
[^] # Re: Comme promis ...
Posté par Victor . Évalué à 1.
Je me suis fait avoir et on m'a dit sur #fluxbox que si background: n'etait pas la, alors fluxbox pensait qu'il n'y avait pas de background de configuré.
[^] # Re: Comme promis ...
Posté par jaroug (site web personnel) . Évalué à 1.
# Bouton droit de la souris...
Posté par maximegb . Évalué à 1.
Et ça, c'est pas pratique avec un touchpad.
[^] # Re: Bouton droit de la souris...
Posté par jaroug (site web personnel) . Évalué à 1.
# Documentation
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
Et je continue, sans cesse, de baver devant les screenshots :D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.