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

    Posté par . En réponse au journal Sortie de Gconf-Cleaner 0.0.3. É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).