Hexchat: HexChat respecte presque la spécification XDG basedir

Que considérez-vous comme des scripts/plugins ?

Bonne question, je ne les ai pas mentionnés car je n'en ai pas (j'ai simplement listé mon ~/.config/hexchat actuel lors de l'ouverture du ticket)

Maintenant, en regardant le package hexchat actuel de Fedora, les plugins de base sont installés dans /usr/lib64/hexchat/plugins , c'est- $libdir/hexchat/plugins dire

Une façon d'examiner la spécification XDG basedir est de la considérer comme une définition spécifique à l'utilisateur de certains chemins standard du FHS.

Les gestionnaires de packages installent des éléments dans /usr , et les administrateurs locaux peuvent installer des éléments manuellement dans /usr/local , afin que cela n'interfère pas avec le gestionnaire de packages.

Dans /usr/local , vous avez exactement la même hiérarchie que dans /usr (moins local lui-même, évidemment), donc vous pourriez avoir /usr/local/share , /usr/local/lib , etc...

La spécification XDG basedir ajoute un niveau supplémentaire au concept /usr -> /usr/local , mais cette fois c'est par utilisateur, et en tant que tel dans leur dossier personnel.

Ainsi, ~/.config peut être considéré comme une version par utilisateur de /etc , ~/.cache comme une version par utilisateur de /var/cache et ~/.local tant que version par utilisateur de /usr (ou /usr/local ).

En tant que tel, vous pouvez avoir ~/.local/share , ~/.local/lib , etc... en fonction des besoins de chaque application. En effet, j'ai un dossier ~/.local/bin ici, qui fait partie du $PATH par défaut sur Fedora.

Donc, si hexchat installe ses plugins à l'échelle du système dans $libdir ( /usr/lib64 sur Fedora), alors les plugins par utilisateur pourraient être installés dans un "per-user $libdir ", par exemple ~/.local/lib/hexchat . (notez que vous voudriez recréer la division lib / lib64 dans la maison de l'utilisateur)

Cela a-t-il du sens?

Oui, tout a du sens et dans un monde parfait, tout irait bien. Le problème est que nous ajouterions beaucoup plus de couches de complexité à l'utilisateur avg. Le simple fait de migrer de xchat vers hexchat peut être une tâche pour beaucoup et lorsque vous commencez à dire qu'aucun plugin ne va ici, mais que les scripts y vont, cela peut être un peu écrasant.

Le cache que je pourrais presque obtenir en tant qu'utilisateur ne devrait jamais s'en soucier, mais dans le passé (pas sûr maintenant), il y a eu des problèmes avec le défilement qui plantait xchat au démarrage et vous deviez les y diriger, maintenant vous êtes juste ajoutant un nouvel endroit où ils ne s'attendraient pas à rechercher lors du dépannage. EDIT : Lors des tests, ce crash semble ne plus exister, donc un autre peut-être.

Quant à la connexion dans la fenêtre des préférences, elle possède un bouton qui devrait ouvrir le "dossier de données" et contrairement aux autres, il est modifiable selon les préférences de l'utilisateur, alors peut-être.

Du côté de la programmation, ce serait beaucoup d'ifdefs laids pour unix car la glib pointe vers tous les mauvais endroits sur Windows et nous avons un mode «portable».

Un programme d'assistance pour migrer de xchat pour les utilisateurs résoudrait le premier problème.

Si nous devions améliorer l'ajout de scripts/plugins pour le chargement automatique au lieu de la méthode actuelle consistant à tout déplacer manuellement, cela rendrait également cela plus faisable.

Problème numéro un : vous supposez en fait que je veux suivre la spécification XDG, ce qui n'est pas vrai.

Si tout avoir dans un seul dossier cohérent (ce qui est le plus pratique pour chaque utilisateur car ils peuvent échanger leurs configurations Unix<->Windows entre autres avantages) vous cause réellement de la douleur , vous pouvez spécifier le chemin complet ou utiliser des liens symboliques pour rendre votre douleur va-t'en. Bien que je recommande également de consulter un psychiatre dans ce cas.

@bviktor, une

Cela ne fait aucune différence à cet égard. Diviser le dossier de configuration en trois n'est tout simplement pas utile.

Il y a en fait une bonne raison pour laquelle les choses ont traditionnellement été séparées. Cela permet plus de flexibilité. Vous pouvez avoir le cache sur un autre système de fichiers (ou même le conserver dans tmpfs, par exemple pour réduire les écritures sur un SSD), sauvegarder les configurations différemment des données, etc.

Mais cela se fait aussi facilement avec des liens symboliques, donc je suis d'accord qu'il ne sert à rien de diviser le dossier. Cependant, avec le cache/les données résidant dans le dossier, ~/.config n'est en quelque sorte pas le bon endroit pour cela. En règle générale, lorsque les développeurs ont l'intention de conserver différentes données dans un seul dossier, elles sont directement mises à la maison. Alors Xchat a bien fait les choses depuis le début ! :)

Alors amusez-vous avec XChat, je suppose.

Problème numéro un : vous supposez en fait que je veux suivre la spécification XDG, ce qui n'est pas vrai.

Je n'ai pas de mots.

@flying-sheep Ses opinions ne reflètent pas tout le monde ;)

J'espère juste que je ne voudrai jamais utiliser un projet qui a un développeur principal avec cet avis.

@flying-sheep Eh bien, il a commencé le projet en tant que version Windows et tout ce que fait XDG est de faire de la mise en page sur Windows un gâchis ou une exception.

Faire abstraction de l'emplacement des fichiers de configuration (ou même de l'ensemble du système de configuration) n'est pas une chose rare à faire.

• Windows vous permet de choisir entre le registre ou les fichiers en %appdata% (ou faire des conneries comme utiliser ~/Documents)
• OSX vous oblige à utiliser ~/Library
• Linux a $XDG_CONFIG_HOME et des amis (ou pour faire des conneries obsolètes comme ~/.projectname)

Il suffit de trouver l'API de son langage/framework pour cela ou d'écrire les 20 lignes de code nécessaires pour cela.

Problème numéro un : vous supposez en fait que nous voulons suivre la spécification XDG, ce qui n'est pas vrai.

Je n'ai pas de mots.

J'espère juste que je ne voudrai jamais utiliser un projet qui a un développeur principal avec cet avis.

Si vous aviez pris la peine de lire au-delà de cette ligne, vous auriez vu une raison à ce choix.

Faire abstraction de l'emplacement des fichiers de configuration (ou même de l'ensemble du système de configuration) n'est pas une chose rare à faire.

Vous prêchez à la chorale. HexChat utilise déjà une telle abstraction (elle est fournie par GTK).

Vous prêchez à la chorale. HexChat utilise déjà une telle abstraction (elle est fournie par GTK).

En fait, nous ne le faisons pas. GLib renvoie %localappdata% nous utilisons %appdata%. Également sur une note latérale pour OS X, il ignore simplement le fait que son OS X et renvoie les répertoires Linux à ma guise.

Mais si l'utilisateur a déjà configuré la synchronisation pour ces répertoires, il pourrait en retirer les avantages si Hexchat les utilisait correctement. Il n'a peut-être pas besoin/voule de synchroniser le journal, mais il peut avoir besoin de la configuration. Ou peut-être souhaite-t-il également synchroniser le défilement, mais pas tout l'historique. Au lieu d'avoir à ajouter plusieurs exceptions au mécanisme de sauvegarde/synchronisation, il sait exactement ce qu'il obtient.

@haarp Eh bien, cette question est de savoir quelle synchronisation est la plus courante, Windows <> Linux ou Linux <> Linux.

(Note pour moi-même : ne parcourez pas GH à partir d'un compte professionnel. Le commentaire original en réponse à https://github.com/hexchat/hexchat/issues/490#issuecomment-36800389 suit.)

Point pris. https://github.com/hexchat/hexchat/blob/b17c0276de4da4cd75114d7e1c67738f894ad59e/src/common/cfgfiles.c#L330 obtient le répertoire appdata en itinérance (d'une manière stupide, en plus) sur Windows ; il n'utilise l'abstraction que sur les non-Windows.

Ensuite, je devine les raisons de le laisser tel quel (par ordre décroissant d'importance):

• Sans code qui détecte et déplace les journaux de XDG_CONFIG_HOME vers XDG_DATA_HOME à chaque démarrage , les mises à jour entraîneront l'indisponibilité de l'ancien défilement (et empêcheront /lastlog de fonctionner ?). Ou nous pourrions simplement les ignorer parce que de toute façon, nous faisons toujours de la rupture des configurations.
• Si l'utilisateur est un adepte des normes, l'envoi de journaux à $XDG_DATA_HOME/logs peut déjà être effectué en spécifiant cela comme répertoire des journaux dans les paramètres de HC. Ou en créant un lien symbolique.
• L'argument de bviktor : L'utilisateur devra maintenir deux répertoires au lieu d'un, où "maintenir" inclut la sauvegarde, le partage entre plusieurs machines, etc.

@TingPing C'est un point valable. Je suppose que si la synchronisation multiplateforme est souhaitée, le mécanisme de synchronisation devrait alors simplement mapper les choses correctement pour nous.

@haarp Comme je l'ai dit, il est déjà possible de dire à HC de mettre le répertoire des journaux en dehors du répertoire de configuration. Ce n'est tout simplement pas la valeur par défaut.

Les scrollbacks ne peuvent pas être déplacés, oui, sans lien symbolique.