Einfügen per mittlerer Maustaste in Claws Mail nur möglich, wenn Quellfenster offen

[Marco Moock]

Hallo zusammen!

Mir fällt gerade was auf:
Wenn ich in einem xterm was markiere und das in ein Fenster von Claws
Mail pasten will, muss xterm währenddessen offen sein.
Kopiere ich von xterm in ein anderes xterm, kann das Quell-xterm
geschlossen sein, der Text kann eingefügt werden.

Bei CM geht das aber nicht.
Was könnte da der Grund sein?

--
Gruß
Marco

[Marcel Logen]

Marco Moock in de.comp.os.unix.x11:

Vermutung:

Wenn das letzte xterm-Fenster geschlossen wird, geht
die "selection" verloren.

Marcel
--
────╮ ╭─╮ ╭─╮ ╭───╮ ╭───╮ ..50..╭───────────╮
╰──╮ │ ╰──╯ ╰─╮ ..27..│ ╰─────╯ ╰────╮ ╰─────────╮ ╰──╮
╰───╯ ..15..╰─╮ ╭──╮ ╭──╯ ╭─────────────╯ ╭─╮ ╭───╯ ╭─╯
╰─╯ ╰─╯ ╰────────────────╯ ╰────╯..63..╰──╮

[Marco Moock]

Am 29.08.2023 um 15:23:11 Uhr schrieb Marcel Logen:

> Wenn das letzte xterm-Fenster geschlossen wird, geht
> die "selection" verloren.

Es betrifft aber nur das Einfügen in Claws Mail - in anderen
Applikationen geht es, auch wenn man es in CM erfolglos probiert hat
geht es hinterher im neuen xterm wieder.

Im Pale Moon (GTK 3) geht es aber ebenfalls nicht.

[Peter J. Holzer]

On 2023-08-29 13:37, Marco Moock <mo...@posteo.de> wrote:
> Am 29.08.2023 um 15:23:11 Uhr schrieb Marcel Logen:
>> Wenn das letzte xterm-Fenster geschlossen wird, geht
>> die "selection" verloren.

Jedes xterm ist ein einständiger Prozess. Das ist daher
unwahrscheinlich.

> Es betrifft aber nur das Einfügen in Claws Mail - in anderen
> Applikationen geht es, auch wenn man es in CM erfolglos probiert hat
> geht es hinterher im neuen xterm wieder.
>
> Im Pale Moon (GTK 3) geht es aber ebenfalls nicht.

Ebenso Firefox und xfce-terminal.

Auch nachdem man es erfolgreich in ein anderes xterm kopiert hat.
Erst nachdem man es dort erneut markiert hat, funktioniert es wieder.

Ich weiß nicht wirklich, wie der Selection/Copy&Paste/Drag&Drop-
Mechanismus funktioniert. Aber es gibt hier sicher zwei Ebenen: Den
ursprünglichen Selection-Mechanismus von X11, den xterm vermutlich noch
immer unverändert benutzt. Und darauf aufbauend den Copy&Paste/
Drag&Drop-Mechanismus von GTK und QT. Letzterer involviert eine
Verhandlung zwischen Quelle und Ziel, also muss die Quelle noch
existieren, wenn das Ziel darauf zugreifen will. Bei ersterem scheint
zumindest minimale Information (der Anfang des selektierten Texts?) im
X-Server gespeichert zu werden und kann somit die Quelle überleben. Aber
GTK- und QT-Applikationen ignorieren das offenbar, wenn die Quelle nicht
mehr erreichbar ist.

hp

[Sieghard Schicktanz]

Hallo Peter,

Du schriebst am Tue, 29 Aug 2023 17:02:47 +0200:

> Ich weiß nicht wirklich, wie der Selection/Copy&Paste/Drag&Drop-
> Mechanismus funktioniert. Aber es gibt hier sicher zwei Ebenen: Den

Vier, aber keine "Ebenen": primary und secondary selection, clipboard und
"buffer-cut". Das sind zumindest die Bezeichnungen, die das Programm
"xclip" dafür verwendet, das diesen Mechanismus auch skriptfähig verwendbar
macht.

> ursprünglichen Selection-Mechanismus von X11, den xterm vermutlich noch
> immer unverändert benutzt. Und darauf aufbauend den Copy&Paste/
> Drag&Drop-Mechanismus von GTK und QT. Letzterer involviert eine

So in etwa dürfte das passen.

> Verhandlung zwischen Quelle und Ziel, also muss die Quelle noch
> existieren, wenn das Ziel darauf zugreifen will. Bei ersterem scheint

Das ist, unter X11, _grundsätzlich_ der Fall. Ist der "Herausgeber" weg,
ist auch der Bufferinhalt weg.

> zumindest minimale Information (der Anfang des selektierten Texts?) im
> X-Server gespeichert zu werden und kann somit die Quelle überleben. Aber

Nein. Das ist eher deswegen so zu beobachten, weil Deine Prämisse, "Jedes
xterm ist ein ei[ge]nständiger Prozess.", nicht unbedingt zutrifft. Es gibt
AFAIK Implementierungen, die einen gemeinsamen Server-Prozess für alle
xterm (oder andere -term*s) starten, ggfs. sogar ohne Wissen des Benutzers,
der dieDatenhaltung für alle Anzeigefenster übernimmt. Wird halt aus
"Geschwindigkeitsgründen" gemacht.

> GTK- und QT-Applikationen ignorieren das offenbar, wenn die Quelle nicht
> mehr erreichbar ist.

Dann verlieren oder ignorieren die evtl. die Verbindung zum Server-Prozeß.
Da hab' ich mich nicht damit befasst, ich habe lediglich für mich einen
kleinen "Clipmanager"-Dialog mit gtkdialog gebastelt, womit ich dieses
Verhalten gut beobachten kann. Wie Qt (KDE) den Mechanismus nutzt, kann
ich mangels solchem nicht sagen.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Peter J. Holzer]

On 2023-08-29 19:12, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
> Hallo Peter, Du schriebst am Tue, 29 Aug 2023 17:02:47 +0200:
>> Ich weiß nicht wirklich, wie der Selection/Copy&Paste/Drag&Drop-
>> Mechanismus funktioniert. Aber es gibt hier sicher zwei Ebenen: Den
>
> Vier, aber keine "Ebenen": primary und secondary selection, clipboard und
> "buffer-cut".

Nein, das ist alles die erste Ebene. Der Mechanismus von GTK und QT
(Xdnd, oder ist das nur ein Teil davon?) setzt darauf auf. Das ist dann
die zweite Ebene.

> Das sind zumindest die Bezeichnungen, die das Programm
> "xclip" dafür verwendet, das diesen Mechanismus auch skriptfähig verwendbar
> macht.
>
>> ursprünglichen Selection-Mechanismus von X11, den xterm vermutlich noch
>> immer unverändert benutzt. Und darauf aufbauend den Copy&Paste/
>> Drag&Drop-Mechanismus von GTK und QT. Letzterer involviert eine
>
> So in etwa dürfte das passen.
>
>> Verhandlung zwischen Quelle und Ziel, also muss die Quelle noch
>> existieren, wenn das Ziel darauf zugreifen will. Bei ersterem scheint
>
> Das ist, unter X11, _grundsätzlich_ der Fall. Ist der "Herausgeber" weg,
> ist auch der Bufferinhalt weg.

So stehts in der Doku, ist aber bei xterm eindeutig nicht so. Probier's
aus:

trintignant:~ 22:14 :-) 1011% ps aux | grep '[x]term'

# kein xterm

trintignant:~ 22:14 :-( 1012% xterm &
[1] 239937
trintignant:~ 22:14 :-) 1013% ps aux | grep '[x]term'
hjp 239937 0.8 0.0 14500 10564 pts/3 S 22:14 0:00 xterm
# Jetzt läuft eines.
# Ich tippe im xterm "Das ist ein Test", markiere es, lösche es und
# beende das xterm mit Ctrl-D.

trintignant:~ 22:14 :-) 1014%
[1] + done xterm

# hat sich brav beendet

trintignant:~ 22:15 :-) 1014% ps aux | grep '[x]term'

# Und weg ist es

trintignant:~ 22:15 :-( 1015% xterm &
[1] 240100

# Auf ein Neues

trintignant:~ 22:15 :-) 1016% ps aux | grep '[x]term'
hjp 240100 0.6 0.0 14500 10444 pts/3 S 22:15 0:00 xterm

# Wie man sieht: Wieder ein xterm, neue PID.
# Ich drücke im xterm die mittlere Maustaste, und voila, da steht
# "Das ist ein Test"

trintignant:~ 22:15 :-) 1017%

>
>> zumindest minimale Information (der Anfang des selektierten Texts?) im
>> X-Server gespeichert zu werden und kann somit die Quelle überleben. Aber
>
> Nein. Das ist eher deswegen so zu beobachten, weil Deine Prämisse, "Jedes
> xterm ist ein ei[ge]nständiger Prozess.", nicht unbedingt zutrifft. Es gibt
> AFAIK Implementierungen, die einen gemeinsamen Server-Prozess für alle
> xterm (oder andere -term*s) starten, ggfs. sogar ohne Wissen des Benutzers,
> der dieDatenhaltung für alle Anzeigefenster übernimmt. Wird halt aus
> "Geschwindigkeitsgründen" gemacht.

Wenn ich "xterm" schreibe, dann meine ich xterm und nicht
gnome-terminal, konsole, xfce-terminal und wie sie alle heißen. Einige
von denen machen das, das weiß ich. Bei xterm hingegen weiß ich sehr
genau, dass jedes xterm ein eigener Prozess ist, und irgendein
zusätzlicher Hintergrundprozess wäre mir noch nie aufgefallen.

Aber ich glaube, ich habe gerade die Lösung in der Wikipedia gefunden:

| Cut buffers, by contrast, provide a passive mechanism: when the user
| selects some text, its content is transferred to a cut buffer, where
| it remains even if the application handling the window terminates and
| the window is destroyed.
-- https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Selections,_cut_buffers,_and_drag-and-drop

Xterm verwendet also offenbar (zusätzlich?) Cut-Buffers. Xdnd hingegen
nur PRIMARY und CLIPBOARD.

hp