Zum eigenlichen Problem (falls Andy Feile noch mitliest): On Fri, 25 Oct 2002, Andy Feile wrote:
Ich wollte doch nur wissen, ob man das Verhalten ändern kann. Aber dank Volker weiß ich es nun auch: nicht ohne Compiler. Nur das wollte ich wissen.
wenn die "Standard"-Anwendung der Maus einfach selektieren ist, und
Copy&Paste via xclipbord eher ein Sonderfall, dann ware es also sinnvoll
dass man den Applikationen beibringt bei dem einfachen selekt **nicht**
in CLIPBOARD zu schreiben, sondern z.B. in CUT_BUFFER2; oder man schalted
einfach ab, dass Selekt ueberhaupt in einem Puffer (CLIPBOARD) landet
Diese Frage ist also mit JA zu beantworten: man kann das Verhalten aendern.
Leider ist eine detaillierte Beschreibung des WIE nicht so einfach, weil
da viele Programme mitspielen (siehe unten).
Brauchst du noch weitere Infos?
Achim
Wer noch Lust hat den Interna von X bzgl. Resource Management zu folgen,
kann ja weiter lesen ;-)
Also ich antworte jetzt nicht mehr explizit auf eine Mail, sondern auf (fast)
alle die sich auf meine Beschreibung bzgl. X bezogen.
Gleich vorweg, ich habe das nicht geschrieben um meine Überlegenheit zu
demonstrieren (es gibt sicher Leute die X noch besser koennen), sondern
weil aus allen Postings zu entnehmen ist/war dass sich bisher niemand die
Muehe gemacht hat zu verstehen was da eignetlich passiert. Das ist kein
Vorwurf, sondern eine Feststellung.
Und diese ausfuehrliche Beschreibung hat sehr wohl was mit dem Problem zu
tun, sie beschreibt eine grundlegende Eigenschaft/Funktion von X. Und die
ist schon fast 20 Jahre alt, und immer noch weit maechtiger als alles was
bei M$ implementiert ist. Das wollen doch viele hoeren, oder? :-]]
xclipboard mit CLIPBOARD bzw. CUT_BUFFERx ist so alt wie X, und ich kann
mich nicht erinnern dass es geandert wurde (seit es funktioniert).
Wer sich nicht vorstellen kann was ich meine (das man alle involvierten
Programme, also X, xrdb, WindowManager, Desktop etc. betrachten muss),
verinnerlicht sich bitte mein Beispiel mit den F1 und F2 Tasten (und meinen
Tipp dazu unten).
Jeder Hinweis dass das pathologisch und/oder nicht der "allgemeine Fall" sei
ist irrefuehrend, bzw. zeugt von Ignoranz gegenueber Leuten die es anders
(als der Default vorsieht, wer definiert das eigentlich?) machen, vielleicht
sogar machen muessen (denkt an die Linkshaender).
Genauso ist die Behauptung, dass man fuer die Bedienung (in diesem Fall
xclipboard) nichts ueber X selbst wissen muss, falsch. Grade bei xclipboard
ist es von entscheidender Bedeutung dass man weiss wie was in welches
X-Property kommt; wenn man xclipboard "nur bedienen" kann, kriegt man u.U.
eben nicht das was man will.
Wen wundert's. Oder warum wurde die Frage wohl urspruenglich gestellt?
Und: nicht *ich* habe die Sache kompliziert gemacht, ich habe nur versucht zu
erklaeren wie komplex sie ist. Diese Komplexitaet hat viele Ursachen: X, xrdb,
KDE, tvwm ... aber sicher nicht ich.
Und wer das immer noch nicht glaubt, probiert mein Beispiel unten aus ...
Den ganzen Aufwand haette ich auch einfach in einer Zeile schreiben koennen:
RTFM
oder genauer: man X&&man xrdb&&man Xlib&&man xclipboard
Man kann RTFM auch sein lassen, aber dann lasst bitte auch die Fragen "warum
funktioniert bei mir das und das nicht".
Ich gebe zu dass das Verhalten von xrdb nur unzureichend in den man-pages
erklaert ist, warum es aber bei SuSE auch mit "xrdb -remove" nicht geht, ist
ist eine andere Geschichte (evtl. KDE oder Gnome, ich habe mir nie die Muehe
gemacht das zu analysieren).
D.h. selbst wer die man-page liest, sich mit den diversen Environmentvariablen
(XRESDIR, XFILESEARCHPATH, etc. etc.) beschaeftigt, und dann probiert sein
privates Class-Resource File zu benutzen, wird nicht zu dem gewuenschten
Ergebnis kommen; gilt nicht fuer jeden, aber die meisten.
Traurig, aber war :-(siehe diverse Kommentare: "geht bei mir nicht" in den
anderen Postings).
Ich habe bewusst auf http://www.mit.edu/ verwiesen, weil AFAIK nur in
aelteren man-pages ueberhaupt noch das spezielle Verhalten von "xrdb -merge"
erwaehnt wird. Die Funktionalitaet wurde wohl nie geaendert, auch nicht in
der Linuxwelt, offensichtlich aber die man-pages. Die Goetter wissen warum ...
(das naechste mal schreibe ich wieder RTFM, und lehne mich dann lachend
zurueck bzgl dem Flamewar:-)
Wie ich schon erwaehnte, zeigen die verschiedenn Postings auch, dass viele
an den (X-) Einstellungen rumgefummelt haben, sonst wuerde ja jeder zum
gleichen Ergebnis kommen.
Ich sage bewusst "gefummelt", weil der "allgemeine Fall" dadurch offensichtlich
(nach Meinung andere Schreiber) pathologisch wurde.
X ist fuer alle da, nicht nur fuer die, die von links nacht rechts und von
oben nach unten und mit dem Zeigefinger der rechten Hand schreiben.
Zu meinem Beispiel mit XTerm und xterm:
dass es bei vielen nicht funktioniert, habe ich vorrausgesagt ;-)
Ursache ist xrdb, ueber Sinn/Unsinn von "xrdb -merge ..." diskutieren wir
lieber nicht; ich gebe dafuer ein Beispiel wie man es testen kann:
Ctrl-Alt-F3 # wechseln auf eine Console
X :3 vt09& # neuen X-Server starten (Annahme: :3 und vt09 ist
# noch frei)
DISPLAY=:3 # sh, ksh, bash syntax
export DISPLAY
# XTerm in ~ anlegen
xterm -title 'XTerm'&
# XTerm veraendern, z.B. F1, F" mit F3, F4 ersetzen
xrdb -merge ~/XTerm
xterm -title 'xrdb' -geo -0+0&
# Aenderung in XTerm rueckgaengig machen
xterm -title 'bang' -geo -0-0&
xterm -title 'test' -geo +0-0 -xrm "`tr -d '\012'