Suggestions de trucs à coder

Elzen · 15-04-2022 20:27:40

Salut! o/

Il m'arrive de temps en temps d'avoir des idées plus ou moins loufoques de trucs à coder dont je sais que je ne passerai probablement pas de temps dessus personnellement, mais dont je me dis que d'une part ce serait quand même fun que le truc existe, rien que pour le principe, et d'autre part ça pourrait être un assez chouette défi technique si quelqu'un a envie de s'y lancer. Aucune garantie que le truc ait un quelconque semblant d'utilité à la fin, mais bon. Je me suis dit que ça pourrait valoir le coup d'ouvrir un fil ici pour venir y poser ces idées, histoires qu'elles ne soient pas perdues. Si quelqu'un souhaite se lancer là-dedans, n'hésitez pas à venir en parler ici !

Et j'inaugure donc ce sujet avec une idée qui vient de me venir en tête, qui serait un peu technique vu que j'imagine qu'elle nécessiterait à la fois FUSE et la Xlib (encore que cette dernière partie pourrait aussi être faite avec une bibli graphique comme GTK, éventuellement) : prendre la règle du « tout est fichier » à la lettre, et faire apparaître les presses-papiers dans le système de fichier.

Je vais commencer par expliquer un peu comment marche la partie que je connais : pour que les différentes applis puissent s'échanger des données, le mécanisme de presse-papier de X identifie différentes « sélections » (il en existe trois par défaut : CLIPBOARD, PRIMARY et SECONDARY, le premier correspondant au truc classique activé par la combinaisons de touches ctrl+c/ctrl+v et compagnie, et le second à la sélection+clic milieu. Le troisième n'est à ma connaissance utilisé nativement presque nulle part. Il est possible d'en créer arbitrairement d'autres, sachant qu'il est recommandé que les noms arbitraires commencent par le caractère « _ ».)
Quand une appli « copie » des données vers un presse-papier, elle envoie en fait simplement un message aux autres applications disant qu'elle gère maintenant la sélection en question, et c'est au moment de « coller » qu'elle envoie réellement les données, suite à une requête reçue d'une autre application (ou d'elle-même si on copie/colle au sein du même logiciel, hein).
Une même application peut fournir simultanément des données plus ou moins différentes (par exemple, si vous « copiez » depuis LibreOffice ou Firefox, vous pourrez « coller » du texte brut dans une appli qui ne gère que ça, mais vous pourrez aussi « coller » les informations de style avec si votre appli de destination les gère). Ça marche parce qu'au moment de « coller », l'application cible précise quel format de données elle veut pour que l'autre lui formate les choses correctement.
Il y a deux « formats » de données qui marchent chaque fois que le presse-papier est utilisé : « TIMESTAMP », qui correspond à un numéro d'événement X ('me semble, je n'ai jamais regardé dans le détail), et « TARGETS », qui correspond à la liste des types de données que le programme qui gère la sélection est capable d'envoyer actuellement. Les autres sont généralement des types mimes correspondant aux données qui peuvent être envoyées, comme « text/plain » ou « image/png », bien qu'il soit en fait possible de déclarer à peu près n'importe quoi (quand on copie du texte, il y a d'ailleurs plusieurs alias différents comme « COMPOUND_TEXT », « UTF8_STRING »…)

L'idée serait donc un programme (façon sshfs ou curlftpfs) à qui on passerait comme arguments la sélection à utiliser et un répertoire cible, et qui nous lance ce qu'il faut dans FUSE pour que, chaque fois qu'on demande à lister le contenu de ce répertoire, on envoie une requête TARGETS et on récupère la liste des formats possibles (il faudra sans doute tricher un peu, j'imagine qu'un type mime « image/png » devra être affiché comme un fichier « png » situé dans un sous-répertoire « image », etc.) Ensuite, ouvrir un fichier envoie une requête sur le format correspond au nom dudit fichier, et renvoie le résultat obtenu.
Dans l'autre sens, si on essaye d'écrire dans un fichier, ça envoie la requête disant que le truc qui tourne en arrière-plan pour gérer ça est maintenant celui qui tient le presse-papier. Ça fera disparaître les fichiers fournis par l'appli précédente, mais en revanche, tant que c'est le truc tournant en arrière-plan qui gère le presse-papier, on peut ajouter différents « fichiers » sans perdre ceux qui étaient déjà là (sauf si on les remplace, évidemment. On peut d'ailleurs aussi imaginer que le programme gère tout seul quelques conversions usuelles, par exemple tous les alias sus-mentionnés pour du texte, mais on peut étendre ça à d'autres trucs. Quand on lui demande de « copier » une image, Firefox est ainsi capable de la convertir en plein de formats différents.)

Qu'en dites-vous ?

Tawal · 15-04-2022 22:52:17

Hello,

Il me semble que le presse-papier est en RAM.
Je vois 2 limitations :
- ssd = pas bon d'écrire/effacer souvent.
- hdd = lent à l'accès (comparé à l'accès RAM) sans compter la surcouche.
edit: on peut tout faire en tmpfs. Mais quand même =>

Et puis, soit j'ai pas tout compris, soit je ne vois pas trop l'intérêt ni le coté "userfriendly".

Dernière modification par Tawal (15-04-2022 23:08:32)

raleur · 16-04-2022 08:09:08

Elzen a écrit :

Quand une appli « copie » des données vers un presse-papier, elle envoie en fait simplement un message aux autres applications disant qu'elle gère maintenant la sélection en question, et c'est au moment de « coller » qu'elle envoie réellement les données

Comment ça se passe quand l'application est fermée ? Visiblement les données collées restent disponibles, alors que l'application n'est plus là pour les envoyer.

vv222 · 16-04-2022 12:22:39

raleur a écrit :

Comment ça se passe quand l'application est fermée ? Visiblement les données collées restent disponibles, alors que l'application n'est plus là pour les envoyer.

J’ai remarqué que ce n’est pas le cas pour le tampon sélection/clic milieu (tampon "PRIMARY" si j’ai bien compris). Je me fais souvent piéger en essayant de copier du texte de cette manière depuis Firefox, que je ne peux plus coller dans une autre application si jamais j’ai fermé Firefox entre temps.

Avec l’explication d’Elzen, je comprends mieux ce comportement qui me perturbait jusqu’ici.

Elzen · 16-04-2022 15:03:25

Tawal a écrit :

edit: on peut tout faire en tmpfs.

Je pense qu'on s'est mal compris

Effectivement, modifier vraiment les fichiers sur le disque à chaque changement du presse-papier serait gênant, pour les raisons que tu mentionnes (et dans un tmpfs, beh, ça nécessite de monter un tmpfs quelque part, ce qui est déjà un pré-requis) ; mais également parce qu'un tel comportement ne suivrait pas la logique de fonctionnement du truc : il faudrait aller requêter les données du presse-papier immédiatement à chaque changement pour créer les fichiers, et pour une appli comme Firefox qui propose plein de formats pour une même image, ça peut faire pas mal de cpu/mémoire à utiliser pour strictement rien.

C'est précisément pour ça que je parlais d'en faire un outil utilisant FUSE, qui permet de monter un système de fichiers virtuel. Quand tu utilises sshfs/curlftpfs, tu ne fous pas en RAM tout le contenu du disque distant : tu montes un truc qui ne va aller lister les fichiers/lire leur contenu sur le disque distant qu'au moment où tu interagiras avec (plus ou moins, je ne connais pas trop les détails de ce côté). Le principe serait ici exactement le même : interroger le presse-papier en temps réel au moment où on essaye de lire/lister les fichiers.

Tawal a écrit :

Et puis, soit j'ai pas tout compris, soit je ne vois pas trop l'intérêt ni le coté "userfriendly".

Je t'invite à relire le premier paragraphe de mon post d'ouverture : il n'y a aucune garantie que ça ait un réel intérêt, c'est juste que je trouve que le truc devrait exister juste pour le principe

En l'occurrence, le seul et unique objectif d'un tel outil serait de permettre d'interagir avec le presse-papier en utilisant les outils de manipulation de fichiers habituels (ls/vim/etc.), de la même manière que le seul et unique objectif des autres outils FUSE est de permettre d'interagir avec d'autres trucs en utilisant les outils de manipulation de fichiers habituels.

Ceci dit, ça pourrait permettre d'interagir un peu mieux (et plus facilement) avec le presse-papier en ligne de commande (et donc pour certains scripts, pour automatiser des trucs, tout ça), dans la mesure où les seuls outils tous faits que je connais pour ça sont assez limités (seul le texte est géré et/ou il n'est pas possible de choisir une sélection arbitraire). Typiquement, certains programmes de gestion d'images (entre autres) en ligne de commande te balancent le résultat vers la sortie standard, charge à toi de le rediriger vers le fichier que tu veux : un tel outil permettrait, plutôt que d'envoyer ça vers un « vrai » fichier, de l'envoyer vers un presse-papier pour ensuite le coller dans un éditeur d'images graphique sans transiter par le disque. Par exemple.

raleur a écrit :

Comment ça se passe quand l'application est fermée ? Visiblement les données collées restent disponibles, alors que l'application n'est plus là pour les envoyer.

Quand une application est fermée, un événement X est généré pour signaler que la sélection choisie est maintenant libre, et les données ne sont plus disponibles. Si ces données sont toujours disponibles chez toi, c'est parce que tu as un programme qui tourne qui les a récupéré au préalable et « prend le relai » automatiquement après cet événement. Plusieurs environnements de bureau fournissent un outil de ce style (ce n'est pas franchement dur à coder, 'faut dire), mais c'est généralement limité au format texte et à la selection CLIPBOARD, comme le fait remarquer vv222.

D'ailleurs, on pourrait tout à fait prévoir une option à cet outil qui permettrait de prendre le relai de cette façon (mais je pense qu'il serait plus intéressant de laisser ça comme une option, dans la mesure où, comme dit plus haut, ça nécessite de récupérer toutes les données du presse-papier à chaque changement et non plus seulement au moment où elles sont interrogées, donc c'est légèrement plus gourmand, surtout si on gère autre chose que le simple texte).

vv222 a écrit :

Avec l’explication d’Elzen, je comprends mieux ce comportement qui me perturbait jusqu’ici.

Mon post aura donc au moins servi à un truc

David5647 · 18-04-2022 10:39:04

Pas sûr d'avoir bien tout compris, mais si c'est plus la finalité que le moyen qui intéresse, regarde du coté de copyq et plus particulièrement de son API

Debian-facile

#1 15-04-2022 20:27:40

Suggestions de trucs à coder

#2 15-04-2022 22:52:17

Re : Suggestions de trucs à coder

#3 16-04-2022 08:09:08

Re : Suggestions de trucs à coder

#4 16-04-2022 12:22:39

Re : Suggestions de trucs à coder

#5 16-04-2022 15:03:25

Re : Suggestions de trucs à coder

#6 18-04-2022 10:39:04

Re : Suggestions de trucs à coder

Pied de page des forums