clipit empeche le copier/coller

Bernard Schoenacker

30/01/2019 à 22:20

----- Mail original -----

De: "Basile Starynkevitch"
À:
Envoyé: Mercredi 30 Janvier 2019 22:04:35
Objet: clipit empeche le copier/coller
Bonsoir,
J'ai observé, aussi bien au boulot qu'à la maison (notamment av ec
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

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 :
https://packages.debian.org/stable/utils/diodon
remarque :
il est possible d'utiliser clipman de xfce en direct
merci
slt
bernard

ajh-valmer

31/01/2019 à 19:00

On Wednesday 30 January 2019 22:04:35 Basile Starynkevitch wrote:

J'ai observé, aussi bien au boulot qu'à la maison (notamment av ec 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 c hose).
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.

=c3

01/02/2019 à 00:40

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.
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
(É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):
https://git.suckless.org/st/file/x.c.html#l268 :
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):
https://git.suckless.org/st/file/x.c.html#l618 :
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:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#selection_atoms
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,
--
Étienne Mollier
Bon sang, on est déjà en février ?

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.

https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html

(É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):

https://git.suckless.org/st/file/x.c.html#l268 :
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):

https://git.suckless.org/st/file/x.c.html#l618 :
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:

https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#selection_atoms

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,
--
Étienne Mollier <etienne.mollier@mailoo.org>

Bon sang, on est déjà en février ?

Vous avez filtré cet utilisateur ! Consultez son message

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.
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
(É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):
https://git.suckless.org/st/file/x.c.html#l268 :
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):
https://git.suckless.org/st/file/x.c.html#l618 :
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:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#selection_atoms
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,
--
Étienne Mollier
Bon sang, on est déjà en février ?

Stephane Ascoet

01/02/2019 à 10:30

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.
--
Cordialement, Stephane Ascoet

clipit empeche le copier/coller

4 réponses

Veuillez sélectionner un problème