Journal Fluxbox 0.9.15

Posté par (page perso) .
Tags : aucun
0
20
mar.
2006
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.
  • # À quand une version stable ?

    Posté par (page perso) . Évalué à 6.

    Ce projet, que j'adore, est vraiment typique d'une certaine extrême modestie des logiciels libres. Je sais pas pourquoi ils appellent cela une version de développement. J'utilise la branche 0.9.x depuis ses tout débuts, 8h par jour, pour mon boulot, et c'est bien simple, il a JAMAIS planté. JA-MAIS. Alors pourquoi pas passer en version stable ? Franchement, ça rime à quoi, de faire traîner pendant des années (2 ans ? 3 ans ? plus ?... je sais plus) une version de dével qui marche nickel pourtant ? Ensuite, les nouvelles versions... À chaque fois que je lis les notes de version, ça me donne pas envie de changer, c'est des tout petits changements de rien du tout - ou alors ils m'apparaissent comme tels, à moi qui ne suis ni programmeur, ni tweaker fou du moindre coin de ma fenêtre.
    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 (page perso) . Évalué à 3.

      Completement d'accord avec toi.

      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 (page perso) . Évalué à 3.

        Oui bon, en même temps, c'est qu'un numéro de version. On n'est pas dans le monde des logiciels proprios où la version 22.6 commercialisée à la FNAC ressemble à une version pre-pre-pre-alpha tellement elle est minable.

        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 . Évalué à 7.

      Alors pourquoi pas passer en version stable

      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 (page perso) . Évalué à 2.

        Ha bon. Bon bon bon... Voilà ce que c'est que d'être un utilisateur final. Merci pour les précisions.
        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 . Évalué à 2.

          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 ?

          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 (page perso) . Évalué à 3.

    Comme promis, la page qui explique al nouvelle manière de changer son fond d'écran http://fluxbox-fr.sysif.net/wikini/wakka.php?wiki=FondEcran
    • [^] # Re: Comme promis ...

      Posté par . Évalué à 1.

      wouhaou.
      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 (page perso) . Évalué à 2.

        Personnellement, j'utilise pwm car je ne veux pas de barre de titre ayant la largeur de la fenêtre... Cependant, je ne bidouille pas mon environnement TOUS les jours ! J'ai personnellement un script qui a tous les paramêtres qui vont bien, je le lance au démarrage et c'est bon. Les rares fois ou je veux modifier un paramêtre, je "restart" mon gestionaire de fenêtre.

        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 . Évalué à 2.

          Simple, c'est ton point de vue, celui d'un utilisateur "normalement constitué" (lambda si tu préfère) est sans doute différent.

          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 (page perso) . Évalué à 2.

            Je suis entouré de gens lambda et ils ne passent pas leur vie au bureau a changer les paramêtres de leur bureau !

            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 . Évalué à 2.

              En l'occurence je pensais à un utilisateur lambda non assisté, qui veut un peu d'autonomie et de liberté pour personaliser son bureau, chez lui par exemple.

              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 (page perso) . Évalué à 2.

                A propose de gconf, il y a des paramètres dans gconf qui sont pris en charge instantanément. Ce n'est pas le cas des fichiers de configuration. Si tu modifie la configuration d'Apache par exemple, il faut lui envoyer le signal HUP pour qu'il recharge a chaud sa configuration. C'est le "restart" des anciens Window Manager basé sur le génial fvwm.

                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 . Évalué à 2.

                  Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément


                  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 (page perso) . Évalué à 2.

                    > Perso je pense que ça peut être bien pratique.

                    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 . Évalué à 1.

      attention car ne pas mettre background: du tout ne permet pas a fluxbox de prendre en compte background.pixmap: !!
      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é.
  • # Bouton droit de la souris...

    Posté par . Évalué à 1.

    Un détail qui m'embête pas mal : pour afficher le menu principal, il faut forcement utiliser le bouton droit de la souris, ce n'est pas paramétrable.
    Et ça, c'est pas pratique avec un touchpad.
  • # Documentation

    Posté par (page perso) . Évalué à 2.

    Le seul problème de Fluxbox je pense est le manque de documentation simple. J'ai essayé plusieurs fois de m'y mettre, impossible de rajouter un thème ou d'avoir un fond d'écran.
    Et je continue, sans cesse, de baver devant les screenshots :D

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.