Journal Sortie de Gconf-Cleaner 0.0.3

Posté par  (site web personnel) .
Étiquettes : aucune
0
8
août
2007
Dans le cadre du Google Summer of Code, est développée une petite application qui fait le ménage dans Gconf. Elle se nomme Gconf-Cleaner et la version 0.0.3 est sortie le 1er Août.

Ce petit outil permet de réduire la taille de la base de registre la base de donnée de gconf. En effet, cette base grandit au fur et à mesure de l'installation et de l'utilisation de logiciels sur votre machine. Il est donc bon, de temps en temps, de la nettoyer.

Cette application permet aussi de sauvegarder ladite base en des fichiers au format .reg....

La principale innovation depuis la dernière version est l'ajout des traductions en allemand, suédois et, surtout pour nous francophones, français.


On peut voir des screenshots là : http://elwario91.tuxfamily.org/

Ça ce passe ici : http://code.google.com/p/gconf-cleaner/

pour l'installer make puis sudo make install

NB: Je signale juste qu'on est pas vendredi :)
  • # ca fait peur...

    Posté par  (site web personnel) . Évalué à 10.

    J'ai compris !!
    Le but de gconf, c'est comme pour la base de registre de windows, c'est de permetre à d'autres softs d'exister !
    Et oui, comment gconfcleaner ferait s'il n'y avait pas de gconf hein !

    Sinon, 25 clé nettoyables sur 2215... vachement intéressant...
    • [^] # Re: ca fait peur...

      Posté par  . Évalué à 2.

      Ca permet aussi et surtout de se passer de la myriade de fichier conf qui se balade dans les ~/.XXXX avec chacun leurs format de fichier, etc etc .
      • [^] # Re: ca fait peur...

        Posté par  (site web personnel) . Évalué à 10.

        Ce qu'on reprochait à Windows <=3.11 ?

        Du coup, on a ce qu'on reproche à Windows >=95.

        Non, je n'ai pas de solution à proposer.
        • [^] # Re: ca fait peur...

          Posté par  (site web personnel) . Évalué à 7.

          Avoir de fichiers disséminés dans des endroits différent, c'est chiant et c'est lourd en gestion. GConf les rassemble en un seul endroit, en ayant le bon gout de documenter les clés (pas comme sous windows). En ayant toutes les clés au même endroit, il devient possible plus facilement de faire un système de cache qui améliore les performances de la lecture d'informations de configuration. De plus, GConf n'est pas passif: il est aussi là pour prévenir ton application quand quand une préférence la concernant a été modifiée, et ainsi agir en conséquence.

          Tu ne peux pas faire ça avec un simple fichier de config.

          Le but de GConf:
          http://www.gnome.org/learn/admin-guide/latest/gconf-1.html

          Des infos ce qu'il faudrait changer dans GConf:
          http://www.gnome.org/projects/gconf/plans.html

          Comm je le dis plus bas, un successeur possible de GConf est Dconf:
          http://live.gnome.org/dconf
          • [^] # Re: ca fait peur...

            Posté par  . Évalué à 6.

            > Avoir de fichiers disséminés dans des endroits différent, c'est chiant et c'est lourd en gestion
            Chez moi, ils sont pas disséminés, mais tous dans ~/.config

            > De plus, GConf n'est pas passif: il est aussi là pour prévenir ton application quand quand une préférence la concernant a été modifiée
            Ça, ça peut se faire avec fam/gamin, pas la peine de sortir l'artillerie lourde...
            • [^] # Re: ca fait peur...

              Posté par  . Évalué à 5.

              Correction: ca peut se faire avec fam/gamin + parsage du fichier de conf + écriture de tout le code qui fait ça tout bien.
              • [^] # Re: ca fait peur...

                Posté par  . Évalué à 5.

                > parsage du fichier de conf + écriture de tout le code qui fait ça tout bien.
                La Glib sait faire ça, hein, il manque plus que l'intégration avec gamin :)
            • [^] # Re: ca fait peur...

              Posté par  . Évalué à 1.

              > Chez moi, ils sont pas disséminés, mais tous dans ~/.config

              Ça m'étonnerais...
              GConf normalise les fichiers de configuration. Lance "gconf-editor" pour te faire une idée.

              > Ça, ça peut se faire avec fam/gamin, pas la peine de sortir l'artillerie lourde...

              Ce n'est pas la même chose.
              GConf peut surveiller par clée par exemple. Inotify, c'est par fichier.
              Si ce mécanisme de GConf est de l'"artillerie lourde", alors Gamin l'est tout autant (en plus il faut ajouter Inotify côté noyau).

              Autre problème que ne gère pas Gamin, il ne sait pas si la modification est terminée. Donc si une opération de modification de Gconf demande deux écritures du fichier, t'es dans la merde...

              Enfin, gconf est un serveur un peu comme un serveur de base de donnée. Il supporte les accès parallèles en lecture/écriture aux fichiers gconf en toute sécurité (rien à voir avec les fichiers .ini).

              Faut vraiment rien y connaitre de gconf pour le critiquer.
              Gconf c'est bien.
              • [^] # Re: ca fait peur...

                Posté par  . Évalué à 6.

                T'excite pas comme ça, on n'est pas vendredi. Tu peux me dire où j'ai dit que GConf c'était de la merde ? Nulle part. Je n'ai fait qu'infirmer le "Tu ne peux pas faire ça avec un simple fichier de config." de liberforce.

                >> Chez moi, ils sont pas disséminés, mais tous dans ~/.config
                > Ça m'étonnerais...
                Heu, écoute, je sais que je suis fatigué en ce moment, mais je sais encore faire un ls -a
                > GConf normalise les fichiers de configuration. Lance "gconf-editor" pour te faire une idée.
                Je n'ai pas dit "mes fichiers de configuration sont tous normalisés" (je m'en contrebalance), mais "mes fichiers de conf sont tous dans ~/.config". Nuance. De taille. Note bien que je ne dis pas ça pour dire "GConf c'est de la merde", mais juste pour infirmer le "Tu ne peux pas faire ça avec un simple fichier de config." de liberforce (encore une fois)

                > Il supporte les accès parallèles en lecture/écriture aux fichiers gconf en toute sécurité (rien à voir avec les fichiers .ini).
                man 2 flock (parce que bon, on parle de bêtes fichiers de config modifiés tous les 36 du mois de grand maximum quelques ko, pas d'un serveur cenralisé qui doit gérer 300000 utilisateurs simultanément)
                Sérieusement, ça t'es déjà arrivé de pourrir un fichier de configuration à cause de deux accès en écriture simultanés ? Parce que bon, même étant très fortement soumis à la loi de Murphy, ça m'est jamais arrivé à moi :p
                > Autre problème que ne gère pas Gamin, il ne sait pas si la modification est terminée. Donc si une opération de modification de Gconf demande deux écritures du fichier, t'es dans la merde...
                Certains utilisent pourtant cette approche (.desktop + gamin) (si mes souvenirs sont pas trop rouillés, XFCE). Ça marche. Aussi bien que GConf. Personne (bon, enfin, disons plutôt pas moi ;)) n'a essayé de dénigrer GConf, alors n'essaye pas de dénigrer d'autres solutions toutes aussi efficaces. Merci.

                > Lance "gconf-editor" pour te faire une idée.
                Désolé de te décevoir, mais j'ai déjà essayé et en plus j'en pense beaucoup de bien. Faut avouer qu'avoir la doc des options comme ça sous les yeux, c'est déjà un avantage nettement plus tangible et intéressant que "ouéch, moi mon gconfd transactionnel il scale aussi bien qu'un MySQL, yeah !"

                [troll (parce que tu cherches, quand même)]
                > Enfin, gconf est un serveur un peu comme un serveur de base de donnée.
                Ben voilà, tu l'as ton artillerie lourde.
                [/troll]
              • [^] # Re: ca fait peur...

                Posté par  . Évalué à 7.

                GConf peut surveiller par clée par exemple. Inotify, c'est par fichier.
                Si ce mécanisme de GConf est de l'"artillerie lourde", alors Gamin l'est tout autant (en plus il faut ajouter Inotify côté noyau).
                C'est a double tranchant tout ça. Si il surveille par clé c'est aussi parce qu'il a en permanance toute la config en mémoire. Et accessoirement si gconf est capable de faire de la surveillance sans inotify, si je me trompe pas, il s'y prend en verifiant les changements a coup de timer. Ce qui est plus gourmand (et chiant si ton disque dur est bruyant) que inotify.

                Enfin, gconf est un serveur [...] (rien à voir avec les fichiers .ini).
                Ou l'art de comparer les carottes avec les castors lapons. En effet rien à voir c'est le mot d'ordre. Tu peux faire un gconf qui écrit dans des fichiers ini, et une appli qui met sa conf directement dans du xml sans gérer les écritures parallèles. Woaw, on est vachement avancé là...

                Faut vraiment rien y connaitre de gconf pour le critiquer.
                Gconf c'est bien.
                Faut vraiment rien y connaitre (tout court) pour voir tout blanc et tout noir.
                • [^] # Re: ca fait peur...

                  Posté par  . Évalué à 3.

                  Je sais pas comment fait gconf en vrai, mais ce serait stupide de faire comme tu as dis.

                  Il suffit que chaque modification passe par des appels à la lib gconf ou au serveur gconf pour intercepter les modifs et faire les notifications demandées si nécessaire, rien de bien lourd ni de bien sorcier.

                  Du inotify en mieux, quoi.
                  • [^] # Re: ca fait peur...

                    Posté par  . Évalué à 0.

                    Euh ou ça en mieux ? Qu'es ce qui m'empêche d'ouvrir le xml et l'éditer ? Qu'es ce qui m'empêche de me faire mon propre daemon qui se charge de la même chose ?
                    • [^] # Re: ca fait peur...

                      Posté par  . Évalué à 3.

                      Qu'es ce qui m'empêche de me faire mon propre daemon qui se charge de la même chose ?


                      Ben rien, si ce n'est que gconf est un mécanisme qui fait déja ça, qui est déja utilisé par pleins d'applis gnome. L'utiliser ou pas, c'est ton problème, si tu veux t'amuser à réinventer la roue ...

                      Euh ou ça en mieux ?


                      Meilleure granularité, celle de l'option de config et pas celle du fichier de conf. Pas besoin de reparser le fichier pour une option à la con.

                      Qu'es ce qui m'empêche d'ouvrir le xml et l'éditer


                      Je sèche, je sais pas si ils ont prévu de surveiller les modifs externes au système gconf en lui même. Déja parce que ça dépend du backend utilisé (bd, fichiers xml, ldap, ... ) Peut être qu'effectivement il y a un système de notification qui vient du backend en lui même, implémenté par notifications de modifs de fichiers pour le backend XML, mais j'ai rien trouvé là dessus rapidement. Dans ce cas, vu la tête des fichiers du backend xml, pas besoin de tout avoir en mémoire, vu qu'il y a basiquement un prog <-> un dossier de config avec un ou des fichiers xml dedans.

                      Trouvé un autre argument là dedans : gestion de parc de machines par backend gconf interposé. Une bonne dose de code à écrire si tu fais ça à ta sauce amha.
                      http://developer.gnome.org/feature/archive/gconf/gconf.html
                      • [^] # Re: ca fait peur...

                        Posté par  . Évalué à 4.

                        Mais il faut faire quoi ici pour eviter d'être pris au pied de la lettre...
                        Non je compte pas recoder un gconf c'était une image pour te dire que surveiller uniquement le fichier a l'aide des appels a la glib c'est une grosse connerie.

                        Et si, tu reparse ton fichier pour savoir ce qui a changé. Ou alors il va falloir m'expliquer comment dans un fichier texte tu trouve les changements avec pour seul information le fait que le mtime est plus le même. Non parce que si tu part du principe que l'utilisateur modifie obligatoirement sa conf avec une appli qui utilise l'api gconf. Dans ce cas il faut prendre l'equivalent sur ton fichier de conf noname, l'utilisateur passe par l'interface de config et donc pas besoin de reparser.

                        Je sèche, je sais pas si ils ont prévu de surveiller les modifs externes au système gconf en lui même.
                        Ben ce serait mieux... interopérabilité tout ça...

                        Peut être qu'effectivement il y a un système de notification qui vient du backend en lui même, implémenté par notifications de modifs de fichiers pour le backend XML
                        Ou peut-être que ta phrase n'a aucun sens ? A ma connaissance tu as deux moyen de savoir si un fichier à changé. La première c'est avec inotify et donc ça reviens au meme que gamin (je rappel que ça part de "gnagnagna gconf c'est mieux parce que entre autre t'as pas besoin de inotify"). La seconde c'est a coup de timer pour voir si le mtime a changé. Et si quelqu'un à pris la peine de faire inotify tu te doute que la seconde solution c'est pas franchement la meilleure.

                        Dans ce cas, vu la tête des fichiers du backend xml, pas besoin de tout avoir en mémoire, vu qu'il y a basiquement un prog <-> un dossier de config avec un ou des fichiers xml dedans.
                        Etrangement mon gconfd ne grossi pas en mémoire quand j'ouvre gconf-editor et que je me balade dans différents dossier. Je l'ai peut-être pas assez remplis pour le voir.

                        Trouvé un autre argument là dedans
                        Quoi déjà a court d'argument pour dire que gconf c'est le bien absolu, l'eden sur terre et que si on ne crois pas en lui on finira dans des camps de concentration de nazi de l'interface ? (c'est énervant de voir ses propos exagérés non ?)

                        gestion de parc de machines par backend gconf interposé.
                        Si tu veux j'ai argument dans l'autre sens. Et j'ai pas eu besoin de le chercher bien loin il tourne actuellement. J'ai daemon (pulse audio) qui tourne avec un uid a lui et qui a besoin de gconfd (oui je sais je peux le mettre avec mon uid mais je vois pas pourquoi je ferais ma conf en fonction des limites que m'impose l'eden sur terre) et ben j'ai deux gconfd en memoire, soit 2fois la taille de ma base de registre. Alors bon c'est pas vraiment ça qui va me faire swapper vu sa taille, mais un fichier de conf par appli aurait éviter le problème. (alors la il faut en déduire que gconf peut être une bonne solution dans certains cas mais pas dans tous, le bon outil pour la bonne tache en opposition avec "ouaaaaaaiiiii du iqusémèleuh je koné sé biaing")

                        Une bonne dose de code à écrire si tu fais ça à ta sauce amha.
                        Je suis "curieux" c'est quoi ma sauce ? Tu m'as vu dire que gconf c'est de la merde point final ? Ou alors j'ai peut être dit que le csv c'etait l'invention du siècle et que jamais on ferait mieux pour la config ?

                        Faut arreter de deduire n'importe quoi juste parce que j'ai osé dire que certains points son contestable. GConf peut être une bonne solution, c'est le cas avec les applis mêmes de gnome qui peuvent partager un bloc de configuration commun, ça à un sens. Mais il y a aussi des desavantages à ça. Faut arreter d'y mettre tout et n'importe quoi (par exemple quand on code un truc qui va possiblement utiliser un uid différent de tout le monde sur la machine).
                        • [^] # Re: ca fait peur...

                          Posté par  . Évalué à 3.

                          Ma phrase était parfaitement sensée, pas forcément claire, mais sensée. Explication de texte : peut être que le backend gconf, le moyen par lequel gconf stocke la configuration, peut donner des infos à gconf quand on on modifie une des clés de manière extérieure. Trigger pour une base de données, fam/gamin, whatever. Dans ce cas il est parfaitement possible que gconf utilise inotify ou dnotify pour ça, j'en sais rien, mais je vois vraiment aucune raison de vouloir s'en priver.




                          teste : strace "lepiddegconfd"

                          J'ai pas l'impression qu'il charge tout en mémoire, pour le backend xml au moins : il ne fait que des "poll" sur un nombre restreint de fichiers, en idle.

                          Après ouverture d'un gconf-editor, il fait des accès dans les fichiers correspondants quand on se balade dans l'arborescence, toujours pas de chargement total en mémoire donc.

                          Pour l'authentification, je sais pas comment ça marche, uniquement par PID ? Au pire, je vois pas pourquoi tes deux instances de gconf devraient charger ta config deux fois, genre l'utilisateur qui fait tourner ton démon il a pas besoin de la config des autres progs.

                          Pour info, XML ou pas XML j'en ai rien a carrer, d'ailleurs c'est pas la seule solution possible.


                          Pour le "c'est l'appli qui modifie sa config", pas forcément, on peut imaginer un wizard de configuration pour une application précise, un panneau de config, des applis de config alternatives, ou encore gconf-editor.
            • [^] # Re: ca fait peur...

              Posté par  (site web personnel) . Évalué à 0.

              > Avoir de fichiers disséminés dans des endroits différent, c'est chiant et c'est lourd en gestion
              Chez moi, ils sont pas disséminés, mais tous dans ~/.config

              Il ne faudrait pas non plus nous faire croire n'importe quoi.
              La convention du répertoire ~/.config/ est une bonne idée mais encore faut-il que les différents logiciels acceptent de l'utiliser et ce n'est pas encore le cas pour un (trop) grand nombre.
          • [^] # Re: ca fait peur...

            Posté par  (site web personnel) . Évalué à 8.

            en fait personnelement j'ai pas grand chose à reprocher à gconf (qu'en réalité je n'utilise que très très rarement tournant sous kde).

            Entre gconf et des fichiers ini, bash ou autre, honnêtement la différence n'est pas très importante (je parle pour l'utilisateur)

            Par contre, ce qui est très très gonflant c'est les applis gnome qui utilisent gconf, qui font que pour le moindre truc à configurer tu es obligé de passer par gconf là où une bête popup et 2 boutons suffirait...
            Et là on commence à tomber sur un peu n'importe quoi...

            m'enfin gnome toussa... (ça aurait été mieux ce journal vendredi, car c'est dur de se retenir :-D)
            • [^] # Re: ca fait peur...

              Posté par  . Évalué à 7.

              Le principal reproche que je ferai à GConf est que celui-ci n'est pas arrété à la fermeture de session.

              Résultat, sur des machines communes genre salle de TP, il est fréquent de trouver une dizaine d'instance de gconfd tournant sous des identifiants différents, alors que les utilisateurs en question ne sont plus connectés.

              C'était du moins le cas sur des machines installées en septembre dernier...
              • [^] # Re: ca fait peur...

                Posté par  (site web personnel) . Évalué à 10.

                Le principal reproche que je ferais à gconf, c'est de rendre illisible la configuration des logiciels. Les fichier texte permettent de récupérer des infos, sont lisibles, et faciles à éditer.

                Si c'est trop lent, on peut toujours les compiler, en faire du xml , des objets sérialisés ou je ne sait quoi d'autre.

                Mais supprimer le format texte des fichiers de conf est vraiment la pire bêtise qu'on puisse faire sur un système Unix dont c'est l'un des précepte de base.

                Au passage, j'en ai presque autant pour kde et son absence de documentation (concernant les fichiers de config).

                Oui, ce n'est pas un reproche technique mais idéologique. Qu'Unix doive évoluer certes. Mais pitié gardons quelque chose de cohérent et pas le daemon land, qui se répand actuellement et qui est tout bonnement imbuvable.

                Une interface simple pour faire des choses de bas niveau svp.
                Aussi simple qu'un /dev/null /dev/zero /dev/dsp /proc/cupinfo /etc/sysconfig/network /etc/inittab ~/.bashrc ~/.muttrc sendmail.cf ....
                Merci
                • [^] # Re: ca fait peur...

                  Posté par  (site web personnel) . Évalué à 10.

                  Aussi simple qu'un [...] sendmail.cf

                  C'est vrai qu'il fait peur ce thread...
                • [^] # Re: ca fait peur...

                  Posté par  (site web personnel) . Évalué à 6.

                  Mais supprimer le format texte des fichiers de conf est vraiment la pire bêtise qu'on puisse faire sur un système Unix dont c'est l'un des précepte de base
                  Je plussoie violemment : y a rien de plus débile qu'un fichier de conf illisible (XML / binaire / format du cosmos) parce que si par hasard l'outil de gestion du fichier conf est malade (plus de serveur X par ex) tu es un peu dans le caca.
                  • [^] # Re: ca fait peur...

                    Posté par  . Évalué à 5.

                    Si ton serveur X a un problème tu auras des choses un peu plus vitales à faire que de lancer gnome.

                    (Bon tu peux me moissonner maintenant :-P)
                    • [^] # Re: ca fait peur...

                      Posté par  (site web personnel) . Évalué à 3.

                      Et quand on veut réparer le Gnome de son petit frère par SSH alors qu'on n'a pas la possibilité de faire du X à distance ?

                      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                • [^] # Re: ca fait peur...

                  Posté par  (site web personnel) . Évalué à 3.

                  Le principal reproche que je ferais à gconf, c'est de rendre illisible la configuration des logiciels. Les fichier texte permettent de récupérer des infos, sont lisibles, et faciles à éditer.
                  ...
                  Au passage, j'en ai presque autant pour kde et son absence de documentation (concernant les fichiers de config).

                  Là tu pointes un problème qui dépasse le simple cadre de l'interface d'accès (fichiers textes ou gconfd) à la configuration : la documentation des options de configuration et de leurs arguments respectifs !
                  Pointer ainsi Gconf est donc une fausse excuse.

                  Une interface simple pour faire des choses de bas niveau svp.
                  Aussi simple qu'un /dev/null /dev/zero /dev/dsp /proc/cupinfo /etc/sysconfig/network /etc/inittab ~/.bashrc ~/.muttrc sendmail.cf ....

                  Comme les interfaces réseaux qui, depuis le début, contreviennent aux fameux « préceptes » d'un système Unix, où tout est fichier ?
                  Que ce soit des fichiers textes ou binaires importe peu tant que c'est bien documenté.
                  • [^] # Re: ca fait peur...

                    Posté par  . Évalué à 1.

                    Que ce soit des fichiers textes ou binaires importe peu tant que c'est bien documenté.


                    Et bien grep, sed ou awk sur du binaire, c'est pas l'idéal...
                    Et certains aiment les UNIXs pour ça justement !
                    • [^] # Re: ca fait peur...

                      Posté par  (site web personnel) . Évalué à 1.

                      Et grep, sed et awk sur des fichiers XML (ou les fichiers de configuration d'Apache dans une moindre mesure), c'est bien ?
                      Rien n'empêche d'utiliser :
                      $ postconf | grep myorigin

                      plutôt que :
                      $ grep myorigin /etc/postfix/main.cf

                      La différence est que si la directive n'est pas définie, la seconde n'obtiendra aucune information et tu devras aller lire la documentation (ou le manuel) pour connaître les arguments par défaut.

                      Exemple :

                      $ grep myorigin /etc/postfix/main.cf
                      #myorigin = /etc/mailname
                      $ more /etc/mailname
                      /etc/mailname: Aucun fichier ou répertoire de ce type

                      $ postconf |grep ^myorigin
                      myorigin = $myhostname
                      $ postconf |grep ^myhostname
                      myhostname = ubuntu

                      Ce n'est qu'un exemple pour démontrer que si les outils de base d'un système Unix permettent de travailler sur des fichiers textes, ils ne sont pas non plus la panacée.
            • [^] # Re: ca fait peur...

              Posté par  . Évalué à 4.

              > Par contre, ce qui est très très gonflant c'est les applis gnome qui utilisent gconf, qui font que pour le moindre truc à configurer tu es obligé de passer par gconf là où une bête popup et 2 boutons suffirait...

              Rien à voir avec Gconf, c'est un choix d'UI de Gnome.

              Il doit bien y avoir des options dans KDE qui ne sont disponibles qu'en bidouille des fichiers .ini. C'est la même chose pour Gnome, sauf qu'on ne bidouille pas des fichiers, on utilise Gconf.
              • [^] # Re: ca fait peur...

                Posté par  . Évalué à 1.

                Il doit bien y avoir des options dans KDE qui ne sont disponibles qu'en bidouille des fichiers .ini.
                Ils ont un moteur de recherche dans leur centre de configuration. C'est pas forcement une bonne chose selon moi mais en tout cas ça en dis long sur ou ils font leurs bidouilles.
              • [^] # Re: ca fait peur...

                Posté par  (site web personnel) . Évalué à 5.

                je reprend car ça doit être compliqué à lire :
                les applis gnome qui utilisent gconf


                Dans la "philosophie" gnome (ou en tout cas ce que j'en ai compris), les fichiers de conf texte ne sont pas vraiment les bienvenue (ce que je conçoit totalement). Mais comme ils ne veulent pas avoir trop d'options dans leur préférences, ils balancent tout dans gconf qui permet une édition graphique des options (comme on le ferai dans un fichier de conf)
                Le problème que j'y voit c'est que pour la moindre option sortant un poil de leur conception, la réponse est : va voir dans gconf ! (idem pour about:config)
                Et là ça devient carrément merdique.
                Je comprend qu'on ne veuille pas proposer n'importe qu'elle option. Mais la solution gconf est à mon avis une mauvaise solution, voilà tout.
                • [^] # Re: ca fait peur...

                  Posté par  (site web personnel) . Évalué à 1.

                  Tu parles de Gconf ou de rediriger l'utilisateur vers l'espace de nommage plus ou moins « caché » où se trouvent les options que les développeurs ne souhaitent pas proposer de base ?
                  Parce qu'en rediriger vers Gconf ou vers un fichier de configuration texte, je ne vois guère la différence...
                  • [^] # Re: ca fait peur...

                    Posté par  (site web personnel) . Évalué à 4.

                    bon, je vais essayer de re-reprendre...

                    Ce que j'aime pas dans les applis _gnome_ (qui utilisent gconf) : <- noter la mise en style précisant encore un peu plus mes idées...
                    sans gconf, deux possibilités :
                    - configuration "classique" pour l'utilisateur via boites de dialogues, quelque soit le système de stockage de la config (il va de soit que cette solution existe aussi avec gconf...)
                    - configuration par fichiers manipulables (texte quoi)

                    Hors, l'un des buts de gnome c'est de proposer l'interface la plus simple possible et la plus dépouillée niveau configuration (en tout cas c'est comme ça que je le ressent). La première solution (présentant toutes les options) n'est donc pas possible, sauf si le soft n'a réellement pas d'option ce qui devient vraiment limité.
                    La deuxième ne l'est pas vraiment non plus car les options ne sont alors pas suffisament aisément modifiables (idem, je trouve, mon sentiment, toussa...)
                    Donc maintenant avec gconf, on peut dire :
                    - l'appli comporte une boite de pref minimaliste (on se demande même parfois pourquoi elle existe)
                    - pour les autres options allez voir dans gconf, c'est bien c'est beau c'est graphique

                    Résultat pour le moindre truc un peu poussé, il faut se tapper une interface merdique vers une base à la base de registre qui en reprend certains défaut (sinon gconf-cleaner n'existerait pas...).
                    J'ai pas dit que j'avais la solution miracle mais bon, un bouton avancé avec un message expliquant que c'est des options plus tordues serait à mon avis mieux.

                    Et on peut toujours dire que rien n'empèche les devs de le faire facilement en se basant sur gconf, reste que ce n'est jamais fait.

                    Voilà, en espérant avoir été un peu plus clair...
                    • [^] # Re: ca fait peur...

                      Posté par  (site web personnel) . Évalué à 3.

                      - pour les autres options allez voir dans gconf, c'est bien c'est beau c'est graphique


                      C'est surtout commenté.
                      C'est l'un (le seul ?) des avantages de gconf.
                • [^] # Re: ca fait peur...

                  Posté par  (site web personnel, Mastodon) . Évalué à 5.

                  En même temps, étant sous Gnome depuis 2.4, je dois être allé dans gconf une dizaine de fois et généralement plus pour débuguer/vérifier des trucs un peu expérimentaux.

                  La seule réelle option que j'utilise courament dans gconf (en fait à chaque nouveau $HOME) c'est "home directory as desktop" et je conçois tout à fait que cette option ne doit pas être dans une UI quelconque mais réservée aux powers users.

                  En fait, ce que beaucoup n'arrivent pas à comprendre c'est qu'il y a une multitude impressionnante de gens qui ne veulent tout simplement pas configurer leurs appli. Ma mère est sous gnome depuis 3 ans, mon père depuis 6 mois et ils n'ont jamais utilisé gconf-editor (ni moi ne l'ai fait pour eux en installant la machine).

                  D'un point de vue pure utilisation, gconf a l'avantage de réduire le nombre de fichiers cachés. On me demande souvent ce qu'est le fatras de répertoire quand les gens ont activés par mégarde l'option "voir les fichiers cachés". Les fichiers cachés rendent le $HOME vraiment merdique. (me faites pas rigoler avec .config, j'ai actuellement 2 applis qui l'utilisent contre 113 qui ont leur propre répertoire caché dans ~ )

                  Après, est-ce que gconf est techniquement meilleur ou pas que d'autres solutions, je sais pas, je laisse les spécialistes en parler. Mais je crois que là, l'utilisateur final il s'en fout

                  Mes livres CC By-SA : https://ploum.net/livres.html

              • [^] # Re: ca fait peur...

                Posté par  . Évalué à 2.

                Exact, tu peux même imaginer un mécanisme qui génère les boite de dialogues automatiquement en demandant à gconf quelles sont les options disponibles dans gconf pour ton logiciel. Genre en ayant une classification et une description correcte des options dans la base.
          • [^] # Re: ca fait peur...

            Posté par  . Évalué à 0.

            je comprends pas bien l'interet de gconf chaque programme a sa propre interface pour se configurer et c'est tres bien pouquoi tout rassembler dans ce truc ?
            l'utilisateur de base n'utilise que ça pourquoi creer ce truc dans des ordinateurs familliaux ou il n'y a pas "d'admnistrateurs"
            un fichier texte peut-etre tres documenté ,gconf l'est autant ?
            je n'ai jamais utilisé ce truc j'ai pris peur avant de faire quoi que ce soit
      • [^] # Re: ca fait peur...

        Posté par  (site web personnel) . Évalué à 6.

        D'où $XDG_CONFIG_HOME
        • [^] # Re: ca fait peur...

          Posté par  (site web personnel) . Évalué à 4.

          Et comme aucun soft n'utilise $XDG_CONFIG_HOME, deux trois lignes en C permettent de forcer la main à ces logiciels trop anciens:
          http://ordiluc.net/fs/libetc/

          On pourrait aller plus loin dans la démarche, par exemple en redirigeant toutes les lectures/écritures dans une base de données par exemple...
          • [^] # Re: ca fait peur...

            Posté par  . Évalué à -1.

            Pas étonnant que les logiciels ne l'utilisent pas, il faudrait déjà que ce soit définit par défaut dans les distributions...

            Ici sur debian sid, $XDG_CONFIG_HOME est initialisé à vide...
      • [^] # Re: ca fait peur...

        Posté par  . Évalué à 7.

        En même temps, je préférais, et de très loin !

        Les fichiers de conf sont différents ? un peu rien à faire, y'a les interfaces pour ça, et ceux qui veulent vraiment le faire à la main y sont généralement habitué.

        Par contre un bon exemple : les messagerie

        1) Thunderbird
        Un dossier. Je veux peu le sauvegarder facilement, juste un dossier à copier

        2) Évolution
        alors là, y'en a dans .gnome2, dans .gconf bref, c'est le bordel

        vraiment gconf, j'ai pas compris son utilité, si c'est reprendre les défauts de Windows.

        Un dossier unique pour chaque application ça me semble quand même plus appréciable.

        De même, il n'y a pas que pour les sauvegardes. Avant si j'avais trop abusé dans la configuration d'un programme et que ça ne marchait plus, j'effaçais le dossier de configuration et c'était repartie. Maintenant, c'est d'un bordel !

        Voilà, c'était juste mon petit coup de gueule parce que vraiment gconf, ça me saoule à un point inimaginable.
        • [^] # Re: ca fait peur...

          Posté par  . Évalué à 3.

          Peut être qu'un man gconftool-2 t'aiderais ... la flemme de fouiller les options, mais a priori t'as de quoi : virer une clé, récursivement, sauvegarder, restaurer une clé.

          Apparemment pas encore moyen de le faire graphiquement avec gconf-editor avec ma version, mais peut être que ça viendra.

          Sinon, a priori, le chemin pour la conf d'une appli spécifique c'est /apps/nomdelappli, voire /schema/nomdelappli.

          En gros, mon humble avis, sauf si il y a des pièges que j'ai pas vu, tu te plains parce que tu sais pas faire, mais ca a pas l'air d'être bien compliquer, genre tu te fais un script bash "virerconfig nomdelappli" avec les option --save nomdufichier --restore nomficxml et roulez jeunesse.
          • [^] # Re: ca fait peur...

            Posté par  . Évalué à 1.

            Ce n'est pas parce que je ne sais pas le faire, car je le fais déjà.
            Je ne dis pas que c'est pas possible, mais beaucoup moins pratique
            Quand je sauve Thunderbird, je sauve .thunderbird et voilà c'est bon
            Pour Evolution, il y a 3 dossier à sauvegarder de mémoire et à remettre dans des endroits un peu caché, en se demandant toujours si l'on a pas oublié quelque chose.
            De plus, ça ne facilite pas le partage de configurations
  • # Question béte

    Posté par  . Évalué à 5.

    Ca fait gagner quoi question perfs le nettoyage de Gconf ?
    • [^] # Re: Question béte

      Posté par  (site web personnel) . Évalué à 3.

      Les clés sont disséminées dans des fichiers xml. Le proflème c'est que lire une multitude de petits fichiers, c'est beaucoup d'I/O, et ça coute du temps. Réduire la taille de ta base réduit le temps d'accès. Ensuite il me semble qu'il y a un système de cache binaire de la base pour éviter les coûts des grosses opérations de lecture. D'aileurs un successeur possible de GConf, Dconf (basé sur DBUS), est en préparation.
      http://live.gnome.org/dconf
      • [^] # Re: Question béte

        Posté par  . Évalué à 3.

        Le proflème c'est que lire une multitude de petits fichiers, c'est beaucoup d'I/O, et ça coute du temps.
        les fichiers supprimés étaient censés être inutilisés, non ? ah ils pompent quand même ? mais alors, gconf c'est pas fait pour être utilisé par plein de programmes à la fois...
        • [^] # Re: Question béte

          Posté par  . Évalué à 1.

          Je n'ai pas regardé GConf-cleaner.
          Gconf peut tourner avec plein de fichiers ou avec un gros fichier. Les deux approches ont leurs atouts/défauts.
  • # Supprime les modifications sur awn

    Posté par  . Évalué à 3.

    Bonjour.

    Gconf-cleaner supprime toutes les modifications faites sur le logiciel awn. (avant-windows-naviguator ; un dock)

    http://code.google.com/p/avant-window-navigator/
    http://njpatel.blogspot.com/2007/07/so-now-that-we-have-some(...)

    L' aspect réflexion comme sur mac os x version leopard, les couleurs, les applets,... .
    Toutes ces modifications peuvent se faire depuis gconf-editor. (ce qui peut expliquer cela) .

    Pas très grave, mais mieux vaut au courant.
  • # Mon commentaire:

    Posté par  (site web personnel) . Évalué à 8.

    Je trouve l'application un peu critiquable, ça devrait juste un peu bénéficier aux administrateurs (et encore). Mais par contre réussir à se faire payer 4500$ pour 1000 lignes de code, pondues depuis début mai, chapeau. Google a mieux dépensé son argent...
    • [^] # Re: Mon commentaire:

      Posté par  . Évalué à 9.

      C'est pas la productivité normale pour toute appli Gnome ?

      O:)
    • [^] # Honte sur moi /o\

      Posté par  (site web personnel) . Évalué à 10.

      Ce projet ne fait pas partie du Google summer of Code, il est simplement hébergé par Google.

      Donc Akira TAGOH ( l'auteur ) n'est pas passé par la case GSoC et n'a pas touché les 4500$...

      Dommage qu'on puisse pas modifier les journaux, là ça le méritait vraiment...

      \_o<

  • # Compile pas chez moi

    Posté par  (site web personnel) . Évalué à 1.

    Hello ça compile pas chez moi, savez vous dire pourquoi ? Sur une Debian SID. juke@porcinet:~/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3$ make make all-recursive make[1]: entrant dans le répertoire « /home/juke/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3 » Making all in src make[2]: entrant dans le répertoire « /home/juke/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3/src » LC_ALL=C ../intltool-merge -d -u -c ../po/.intltool-merge-cache ../po gconf-cleaner.desktop.in gconf-cleaner.desktop Found cached translation database Merging translations into gconf-cleaner.desktop. make[2]: quittant le répertoire « /home/juke/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3/src » Making all in po make[2]: entrant dans le répertoire « /home/juke/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3/po » file=`echo de | sed 's,.*/,,'`.gmo \ && rm -f $file && -o $file de.po /bin/sh: line 1: -o: command not found make[2]: *** [de.gmo] Erreur 127 make[2]: quittant le répertoire « /home/juke/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3/po » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /home/juke/Desktop/tmp/gconfcleaner/gconf-cleaner-0.0.3 » make: *** [all] Erreur 2
  • # Et en console ?

    Posté par  . Évalué à 2.

    Existe-t'il un mode sans interface graphique afin de pouvoir lancer l'outil en batch sur son parc ?
  • # Vive E17

    Posté par  . Évalué à -8.

    Pourtant fana de Gnome, je l'ai abandonné. Trop lourd et tournant de plus en plus à l'usine à gaz.
    E17 fait le boulot, avec légèreté. J'ai l'impression d'avoir changé de machine.
    La version CVS 200708 fonctionne bien sur Etch
    Il suffit d'ajouter ce dépôt dans le /etc/sources.list de Etch.
    deb http://repository.elive-systems.com elive main efl elive tests
    Ne pas oublier "tests". à la fin sinon on a le droit au CVS 2006. Cela semble mis à jour chaque mois.
    Avant de lancer E17, supprimer dans le /home tout ce qui concerne enlightenment.
    • [^] # hein ?

      Posté par  (site web personnel) . Évalué à 2.

      ... il a rien à voir avec la choucroute ton commentaire !
      • [^] # Re: hein ?

        Posté par  . Évalué à -6.

        Merci pour courageux moinssage.
        Mon commentaire montre comment je me suis débarrassé de gconf & gnome.
        Ce gconf-cleaner montre qu'il y a un problème.
        Quand je lis tout ce qui se dit plus haut à propos de ce "cleaner", ça me rappelle le cauchemard de w$_nortonmachin_etc. C'est ce qui m'a fait quitter le monde de w$ il y a 9 ans exactement. C'est quand même dommage de voir autant de gens devenir prisonniers des grosses usines gnome, kde, xfce .
        • [^] # Re: hein ?

          Posté par  . Évalué à -7.

          Au lieu de moinsser, ne serait il pas plus utile d'expliquer pourquoi on est en désaccord avec un commentaire ?
          • [^] # Re: hein ?

            Posté par  (site web personnel) . Évalué à 2.

            Comme Thomas vient de le dire, ton commentaire est inutile et rien à voir avec le sujet du journal.

            Pour rappel, le journal parle d'une application gconf-cleaner et tu nous parles comment installer e17, puis une ligne avec un vague rapport avec le logiciel puis tu enchaines avec des prisonniers des environnements de travail...

            Autant dire le rapport signal/bruit est très faible..
            • [^] # Re: hein ? La Cathédrale ou le Bazar ?

              Posté par  . Évalué à -6.

              Quel jugement lapidaire :
              "inutile", "rien à voir" "vague rapport".
              Désolé, mais mon commentaire est tout à fait utile même s'il ne respecte pas les normes policées de linux.fr. Mon commentaire n'est pas hors sujet mais part de Gnome que je connais bien pour l'avoir utilisé pendant des années. Je ne m''avancerai pas à critiquer KDE que je connais mal. Donc je critique Gnome, en relatant mon expérience, en proposant E17 et en essayant de montrer que l'install de E17 est plus simple qu'on ne le croit. Ton commentaire, je m'en excuse d'avance, est quelque peu intolérant. Il est loin de la démarche positive et fructueuse de ceux qui tentent de perpétuer l'esprit "bazar" de GNU/Linux pour le faire avancer, en tant que programmeurs ou utilisateurs.
              http://www.linux-france.org/article/these/cathedrale-bazar/c(...)
              • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                Posté par  (site web personnel) . Évalué à 6.

                les applies qui utilisent gconf, c'est pas juste le window-manager de Gnome. C'est toutes les applies gnome, et d'autres (firefox par exemple). Donc, installer E17, ça va pas changer grand chose à la question to-gconf-or-not-to-gconf ...
                • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                  Posté par  . Évalué à 2.

                  Bonsoir
                  J'ai désinstallé gconf. J'utilise toujours Iceweasel, thunderbird, Gimp, synaptic et d'autres applis gtk2. J'ai remplacé nautilus par thunar, gnome-terminal par xfce4-terminal (plus rapide), etc..
                  Bref, je me passe de Gnome et de gconf, j'espère que cela va pouvoir durer.
                  • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                    Posté par  . Évalué à 3.

                    "Bref, je me passe de Gnome et de gconf, j'espère que cela va pouvoir durer."
                    T'as essayé les associations des alcooliques utilisateurs de Gconf anonymes?

                    :-p
                    • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                      Posté par  . Évalué à -1.

                      Non, mais ça mais ça m'a permis de remettre les pendules à l'heure.
                      Je suis simple utilisateur, donc pas expert, mais les gens qui bossent sur Enlightenment font un boulot formidable, d'après ce que je constate. Ils ont choisi un chemin de traverse en se lançant dans E17, EFL, etc..C'est tout l'esprit des pionniers de GNU/Linux qui est là. Je trouve bizarre que relativement peu de gens en parle.
                      • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                        Posté par  . Évalué à 3.

                        Ils ont eu leur heure de """gloire""" sur linuxfr et ailleurs y'a 2 ans environ. À l'époque, X.org venait de faire passer Composite dans sa branche stable, mais le seul composite manager répandu était basé sur XRender, très très mal accéléré par les pilotes. Et donc les ombres et la transparence c'était hyper lent avec X, alors que E17 c'était magique ça faisait de la transparence et des ombres rapides.
                        Bon avec Compiz/Beryl les gens ont compris que c'était pas X le problème, et que la transparence et les ombres dans E17, c'est du flan (dessiner les ombres sur le fond d'écran, ça ne fait pas un effet d'ombre rendant l'affichage plus agréable vu que des fenêtres se chevauchant n'auront pas des ombres qui se chevauchent)

                        Sinon, juste comme ça, dans E17 y'a la gestion du copier/coller maintenant ? Je suis sérieux hein, y'a un an, aux RMLL, le mec a découvert lors de la présentation qu'il n'y avait pas de copier/coller, et il a remarqué que c'était pas dans la liste des choses à faire et donc que ça n'allait pas être fait avant la sortie d'une version stable...
                        • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                          Posté par  . Évalué à -1.

                          En étant très sérieux, c'est une blague cette histoire de copié-collé ?
                          Cela concernerait plutôt GTK si il y avait un souci. Je me sers de E17 (sur Etch) tous les jours, pour travailler en autres. Donc je m'en serai aperçu vu le nombre de copiés-collés/jour. Quant aux ombres, ce n'est pas ce qui m'intéresse et je les ai désactivées.
                          • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                            Posté par  . Évalué à 2.

                            Oui, c'est très sérieux, ce n'est pas une blague.
                            E17 c'est pas un gestionnaire de fenêtres. Je te parle des librairies d'E17 et donc des applications écrites avec ces librairies (je me rappelle plus les noms de ces applications par contre)
                        • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                          Posté par  . Évalué à 2.


                          [...] et il a remarqué que c'était pas dans la liste des choses à faire et donc que ça n'allait pas être fait avant la sortie d'une version stable...


                          si une version stable sort un jour. Non pas que dans l'état actuel ce soit instable mais je commence à croire qu'ils préfèrent ne pas proposer de version stable un jour mais tout simplement dire aux gens « prenez le SVN ».
                  • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                    Posté par  (site web personnel) . Évalué à 1.

                    C'est facile pour toi : aucune des applications que tu viens de citer n'utilise Gconf.
                    Par contre, tu pestes contre Gconf mais que penses-tu des about:config des logiciels de Mozilla ? Est-ce vraiment mieux ?
                    • [^] # Re: hein ? La Cathédrale ou le Bazar ?

                      Posté par  . Évalué à -1.

                      Salut
                      < C'est facile pour toi : aucune des applications que tu viens de citer n'utilise Gconf
                      Non, ce n'est pas facile. C'est un choix. J'ai du éliminer toutes les applis qui utilisaient gconf et que j'utilisais depuis lontemps, par ex :
                      gnome-system-monitor remplacé par qps
                      nautilus par thunar
                      Par contre, comme je veux afficher des .xcf pour bosser, je suis obligé d'utiliser konqueror + gimp . Le tout reste très rapide avec E17. KDE n'a jamais été ma tasse de thé, mais konqueror est la seule appli qui affiche correctement les .xcf.

                      < que penses-tu des about:config des logiciels de Mozilla
                      Je n'utilise quasiment jamais about:config. Où est le problème ?
        • [^] # Re: hein ?

          Posté par  (site web personnel) . Évalué à 6.

          Ce gconf-cleaner montre qu'il y a un problème.

          Quel problème ? Le fait que des applications ne sachent pas effacer les clés de configuration qu'elles ont déposé après la première utilisation lors qu'on ne veut plus s'en servir ? En quoi est-ce de la faute à Gconf ?
          Ce problème se pose également pour les fichiers de configuration dissiminés dans $HOME $XDG_CONFIG_HOME : qu'adviendra-t-il des fichiers qui ne servent plus à rien parce qu'on n'utilise plus l'application qui s'en sert ? Ce n'est pas un souci de performance que de vouloir faire un peu de ménage dans ces fichiers.
          • [^] # Re: hein ?

            Posté par  . Évalué à -4.

            < Quel problème ?
            Mon propos, c'était que gconf fait partie de Gnome et c'est Gnome dans sa globalité qui pose des problèmes de lourdeur et de lenteur. Idem pour KDE et autres. Et puis le fait d'en arriver à être obligé de nettoyer comme le font ceux qui utilisent w$ .......
          • [^] # Re: hein ?

            Posté par  . Évalué à -2.

            Je n'avais pas saisi.
            J'ai supprimé gconf. OK
            Les fichiers de config perso inutiles sont dans des répertoires situés dans le /home, facilement identifiables, peu nombreux et peu volumineux. Un coup de "MC" et c'est supprimé. Je fais ça depuis longtemps sans aucuns soucis.
  • # Critères de sélection ?

    Posté par  (site web personnel) . Évalué à 10.

    Sur quels critères de sélection Gconf-cleaner va-t-il se baser pour déclarer que certaines clés doivent être ou non supprimées ?

Suivre le flux des commentaires

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