gratifiant > linux.debian.user.french

Basile Starynkevitch (30/01/2019, 23h10)
Bonsoir,

J'ai observé, aussi bien au boulot qu'à la maison (notamment avec XFCE
ou LXDE comme environment de bureau) que l'installation du paquet clipit
casse le copier/coller.

J'ai résolu le problème avec un aptitude purge clipit, mais je n'ai pas
compris ce problème (car pour moi, le copier/coller serait géré par X11
en suivant ICCCCM & EWMH; il relève du window manager, pas d'autre chose).

Quelq'un a une explication?

Il y a plus de 30 ans, j'avais lu en détail la doc (une dizaine de
pavés) de X11 - à l'époque des stations Sun - et j'avais tâté NeWS. Mais
j'ai oublié la plupart des détails.

Cordialement
Bernard Schoenacker (30/01/2019, 23h20)
----- Mail original -----
[..]
> Mais
> j'ai oublié la plupart des détails.
> Cordialement


bonjour,

personnellement j'utilise diodon qui est également en gtk+

apt-cache search diodon
diodon - gestionnaire en GTK+ du presse-papier
diodon-dev - GTK+ Clipboard manager (development files)
gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
libdiodon0 - GTK+ Clipboard manager (main library)

détail du paquet :


remarque :

il est possible d'utiliser clipman de xfce en direct

merci
slt
bernard
ajh-valmer (31/01/2019, 20h00)
On Wednesday 30 January 2019 22:04:35 Basile Starynkevitch wrote:
> J'ai observé, aussi bien au boulot qu'à la maison (notamment avec XFCE
> ou LXDE comme environment de bureau) que l'installation du paquet clipit
> casse le copier/coller.
> J'ai résolu le problème avec un aptitude purge clipit, mais je n'ai pas
> compris ce problème (car pour moi, le copier/coller serait géré par X11
> en suivant ICCCCM & EWMH; il relève du window manager, pas d'autre chose).
> Quelq'un a une explication?
> Il y a plus de 30 ans, j'avais lu en détail la doc (une dizaine de
> pavés) de X11 - à l'époque des stations Sun - et j'avais tâté NeWS. Mais
> j'ai oublié la plupart des détails.


Le copier/coller fonctionne mal chez moi aussi avec Libreoffice,
grâce à la molette.
Défaut inhérent depuis toujours ainsi que OO.
Étienne Mollier (01/02/2019, 01h40)
Basile Starynkevitch, au 2019-01-30 :
> J'ai observé, aussi bien au boulot qu'à la maison (notamment
> avec XFCE ou LXDE comme environment de bureau) que
> l'installation du paquet clipit casse le copier/coller.
> J'ai résolu le problème avec un aptitude purge clipit, mais je
> n'ai pas compris ce problème (car pour moi, le copier/coller
> serait géré par X11 en suivant ICCCCM & EWMH; il relève du
> window manager, pas d'autre chose).


Bonsoir,

J'ai passé a peu près quatre heures à « essayer tout plein de
trucs », avant de me rendre compte que, bah en fait, je n'y
comprends rien du tout au fonctionnement des presse-papiers du
serveur X ; donc mon analyse vaudra ce qu'elle vaudra...

Il semblerait que le chargement et le déchargement des tampons
de stockage des copier/coller primaire (clic milieu de souris),
secondaire et presse-papier (copier/coller classique), soit la
responsabilité des divers clients X, via l'usage de la
bibliothèque Xlib. ICCCM définit des conventions quant au bon
usage du serveur X par les applications diverses et variées,
gestionnaires de fenêtres et autres utilitaires.



(Étant donné qu'il s'agit de conventions, rien n'empêche un
certain nombre de programmes d'y contrevenir.)

En cherchant des exemples de manipulation de presse-papier dans
la nature, l'émulateur de terminal `st`, dans son fichier `x.c`,
comprend les fonctions:

- selpaste, qui implémente en partie le collage de sélection
avec la fonction XConvertSelection(3):

:
void
selpaste(const Arg *dummy)
{
XConvertSelection(xw.dpy, XA_PRIMARY, xsel.xtarget, XA_PRIMARY,
xw.win, CurrentTime);
}

- setsel, qui implémente le remplissage du tampon primaire en
fonction du texte sélectionné dans le terminal, en utilisant
une combinaison des fonctions XSetSelectionOwner(3) et
XGetSelectionOwner(3):

:
void
setsel(char *str, Time t)
{
if (!str)
return;

free(xsel.primary);
xsel.primary = str;

XSetSelectionOwner(xw.dpy, XA_PRIMARY, xw.win, t);
if (XGetSelectionOwner(xw.dpy, XA_PRIMARY) != xw.win)
selclear();
}

Je n'exclue pas d'avoir tout compris de travers, mais
manifestement il se passe quelque chose avec ces fonctions
X*Selection*. Apparemment à aucun moment cette information ne
semble remontée au serveur X ; le contenu de la chaîne de
caractère est certes transféré à la structure xsel, mais
n'apparaît pas dans les appels de fonctions.

Mon gestionnaire de fenêtre est dwm. En partant du principe que
les fonctions ci-dessus servent bien à la gestion de sélections,
et si on en juge par un rgrep du code source de dwm, il ne
devrait pas interférer avec la sélection de texte :

$ rgrep 'X.*Selection.*' dwm-6.1/
Exit code: 1

Tentant une expérience, je lance deux fenêtres st, gérées par
dwm. Je sélectionne un texte dans la première fenêtre st que je
colle dans la seconde fenêtre via un clic milieu. En prenant
garde à ne pas perdre la sélection, je me déconnecte du premier
terminal via Ctrl+D et je fais un clic milieu dans la seconde
fenêtre: j'observe qu'il n'y plus de collage de texte.

Expérience suivante, toujours dans dwm, je lance trois instances
de st. Dans l'une est lancé `clipit -d`, le processus tourne
tranquillement sans rendre la main, on n'y touche plus. Je
copie du texte du second terminal, que je colle dans le
troisième. Je termine la seconde instance de st de la même
manière que l'expérience précédente, et effectue un clic milieu
de souris dans le terminal numéro trois: j'observe cette fois ci
que le contenu à coller est toujours disponible. Enfin, si je
tue le processus clipit, toujours en cours d'exécution dans le
premier terminal, alors le texte est à nouveau indisponible au
collage.

Mon interprétation est que, sans intervention extérieure, le
contenu du PRIMARY dépend de l'état de la fenêtre source, ce qui
me pousse à croire que chaque client X a son propre PRIMARY, et
que des outils comme clipit permettent de sauvegarder ces
tampons en cas de fin du processus qui a émis le contenu source.
Le document ICCCM fait mention de ces « clients spéciaux »
dédiés à la gestion des copier/coller:



On peut y lire d'une part, à propos des clients de type
« presse-papier » qu'ils doivent récupérer la main dessus à
chaque évolution dans les données :
> It should assert ownership of the CLIPBOARD selection and
> reassert it any time the clipboard data changes.


Et d'autre part, si on jette un coup d'?il rapide au code source
de xfwm4, le gestionnaire de fenêtres de Xfce, on peut avoir
l'impression que, peut-être, il n'est pas neutre vis-à-vis de la
manipulation des tampons du presse-papier (note: je n'ai pas
pris le temps de tester), et que donc parmi ses attributions, il
pourrait prendre la responsabilité de centraliser le CLIPBOARD :

$ rgrep 'X.*Selection.*' xfwm4-4.12.5/
xfwm4-4.12.5/src/compositor.c: if (XGetSelectionOwner (display_info->dpy, a) != None)
xfwm4-4.12.5/src/compositor.c: if (XGetSelectionOwner (display_info->dpy, a) != None)
xfwm4-4.12.5/src/hints.c: status = XSetSelectionOwner (display_info->dpy, atom, w, server_time);
xfwm4-4.12.5/src/hints.c: if (XGetSelectionOwner (display_info->dpy, atom) == w)
xfwm4-4.12.5/src/hints.c: systray_win = XGetSelectionOwner (display_info->dpy, net_system_tray_selection);
xfwm4-4.12.5/src/screen.c: current_wm = XGetSelectionOwner (display_info->dpy, wm_sn_atom);
xfwm4-4.12.5/src/events.c:handleSelectionClear (DisplayInfo *display_info, XSelectionClearEvent * ev)
xfwm4-4.12.5/src/events.c: status = handleSelectionClear (display_info, (XSelectionClearEvent *) ev);

Clipit semble avoir des fonctions équivalentes, mais basées sur
la bibliothèque GTK+ ; `rgrep gtk_clipboard_get` renvoie pas mal
de lignes aussi.

> Quelq'un a une explication?


Sachant que l'heure de la capture de la copie fait partie des
données du presse-papier (variable server_time dans xfwm4), mon
ressentit dans tout ça est que: le gestionnaire de fenêtres et
clipit font du pingpong, en mettant à jour à chaque itération la
date des données du presse-papier, le rendant inutilisable dans
la man?uvre.

Mais peut-être que je me trompe: il n'y a pas de problèmes quand
deux instances de clipit sont en train de tourner simultanément,
alors que je m'attendais éventuellement à ne plus pouvoir
effectuer ni copies ni collages...

> Il y a plus de 30 ans, j'avais lu en détail la doc (une
> dizaine de pavés) de X11 - à l'époque des stations Sun - et
> j'avais tâté NeWS. Mais j'ai oublié la plupart des détails.


Désolé pour l'interprétation très empirique et un peu brouillon,
je n'ai pas les volumes dans ma bibliothèque. J'espère que ça a
fait un peu sens néanmoins. :^)

ajh-valmer, au 2019-01-31 :
> Le copier/coller fonctionne mal chez moi aussi avec Libreoffice,
> grâce à la molette.
> Défaut inhérent depuis toujours ainsi que OO.


Pour ce qui est des suites bureautique Star/Open/LibreOffice,
manifestement, une fonction a été implémentée pour s'exécuter
lors d'un clic milieu de la souris, et ne consiste pas toujours
à copier le contenu du tampon primaire. Je suis d'accord, ce
n'est pas très ergonomique. :^(

Amicalement,
Stephane Ascoet (01/02/2019, 11h30)
Le 30/01/2019 à 22:04, Basile Starynkevitch a écrit :
> il relève du window manager, pas d'autre chose).


Bonjour, pour moi ca releve plutot du serveur X. Meme sans gestionnaire
de fenetre, c'est cense fonctionner.
> Quelq'un a une explication?


Ben vu que Clipit est un gestionnaire de presse-papiers, il doit
intercepter des trucs d'une facon incomplete ou incorrecte.
humbert.olivier.1 (02/02/2019, 21h20)
Bonsoir Basile et tout le monde,

Simplement pour confirmer que j'ai observé le même phénomène avec le Clipit dans Buster.
Par contre, aucun soucis avec celui de Stretch.
Ceci en utilisant MATE.

Le bogue a déjà été reporté ici : et ici :

Je n'aurai pas le temps d'ajouter des éléments de confirmation dubogue dans les prochains jours, et tâcherai de le faire ensuite. Je vous encourage à faire de même.

Olivier
Discussions similaires