# kde4 und xterm

## SarahS93

Benutzte KDE4 und xterm-.

Mit STRG und Mausrad-mitte kann ich im xterm-Fenster "Clipboard" auswählen, so wird dann der mit der Maustaste-links makierte Text in den Zwischenspeicher kopiert von dem ich dann auch aus z.B kwrite zugrif darauf habe. Da ich aber nicht bei jedem xterm-Fenster diese Option wähle möchte nun die Frage, wie geht das dauerhaft zu machen? Mit welcher Option muss ich xterm aufrufen?

Im KDE4 kann ich das xterm-Fenster in der Titelleiste clicken und weiter Optionen wählen, dann keinen Rahmen. Wie kann ich auch dies dauerhaft für xterm machen?

----------

## Christian99

zu deiner zweiten frage: unter weiter aktionen hast du auch einen punkt "spezielle eistellungen für dieses Fenster/Programm" da kannst du das einstellen für alle fenster eines programms oder für spezielle fenster

----------

## SarahS93

Naja, ich will das ja nicht für jedes xterm Fenster.

----------

## Christian99

was meinst du dann mit dauerhaft?

----------

## SarahS93

Also, ich habe in meinem KDE4 vier Arbeitsflächen eingerichtet.

Auf Arbeitsfläche 1 will ich nur xterm-Fenster ohne Rand haben.

Ich will wen ich mein System hochfahre auf der Arbeitsfläche meine 10 xterm-Fenster haben in denen verschiedene Programme laufen/Meldungen angezeigt werden.

Diese 10 xterm-Fenster starte jeweils mit unterschiedlichen xterm-Fensterauflösungen und verschiedenen Positionen (hat lange gedauert alles gut auszurichten auf der Arbeitsfläche).

Das funktioniert soweit alles wie ich will, nur will ich das diese 10 xterm-Fenster auf Arbeitsfäche 1 immer ohne Rand gestartet werden, wobei ich aber will wenn normal. über z.B ALT und F2 > xterm ich ein xterm-Fenster starte, soll dieses ein Rahmen haben, damit ich es verschieben kann usw.

Weiterhin will ich nicht bei jedem mal wenn die besagten 10 xterm-Fenster aufgerufen werden in jedem einzelnen STRG und Maus-mitte clicken müssen und dann "select to Clipboard" anwählen müssen.

Daher brauche ich diese beiden Optionen als befehl zum eintippen, damit ich es in mit die Zeilen meiner 10 xterm-Fenster einfügen kann.

----------

## py-ro

Ich kenne keine direkte Lösung dafür, da KDE in dem Fall schlicht nicht wissen kann welches xterm was sein soll.

Was du probieren könntest, was mir gerade spontan in den sinn kam, mach nen symlink/hardlink auf xterm mit einem anderen Namen, z.B. xterm-borderless, und nutze dies für die genannten Fenster und erstelle für dieses Programm die Regel.

Nicht getestet, könnte aber funktionieren.

By

Py

----------

## SarahS93

Das könnte hinhauen, ich teste und Berichte ....

----------

## Christian99

du kannst auch mit dem xterm switch "-T <title>" einen eigenen Titel für dein xterm setzen und kde kann den Fenstertitle matchen. das sollte auch gehn.

----------

## musv

 *SarahS93 wrote:*   

> Mit STRG und Mausrad-mitte kann ich im xterm-Fenster "Clipboard" auswählen, so wird dann der mit der Maustaste-links makierte Text in den Zwischenspeicher kopiert von dem ich dann auch aus z.B kwrite zugrif darauf habe.

 

Das geht auch einfacher. Ohne "Clibboard" einfach einen Text mit der linken Maustaste markieren und im Kwrite mit der mittleren einfügen. 

Ansonsten dürfte die .Xdefaults dafür zuständig sein:

http://blog.bigsmoke.us/2010/01/31/xterm-clipboard-selection

https://wiki.archlinux.org/index.php/Xterm#PRIMARY_and_CLIPBOARD

 *SarahS93 wrote:*   

> Im KDE4 kann ich das xterm-Fenster in der Titelleiste clicken und weiter Optionen wählen, dann keinen Rahmen. Wie kann ich auch dies dauerhaft für xterm machen?

 

Die Rahmengestaltung der Fenster wird vom Fenstermanager (kwin) geregelt. Im xterm gibt's eine Option "-bw" (border width) allerdings mit der Eklärung:

 *man xterm wrote:*   

>  This appears to be a legacy of older X releases.  It  sets  the
> 
> borderWidth  resource  of  the  shell  widget,  and may provide
> 
> advice to your window manager to set the thickness of the  win‐
> ...

 

Und desktopabhängig wirst du das vermutlich nicht setzen können.

----------

## SarahS93

xterm-boarderless funktioniert

su

cd /usr/bin

ln -s xterm xterm-boarderless

alt+f2

xterm-boarderless

alt+f3  >  weiter aktionen  >  spezielle einstellungen für programm  >  erscheinungsbild & korrekturen  >  ohne titelleiste und rahmen : bei initalisierung anwenden - ja

Das ganze über den titel im fenster zu lösen will irgendwie nicht ... ist auch sehr viel klickerei die ich nicht so mag :/

Hehe, toll, mausrad drücken im kwite - wer denkt denn auch an sowas, funktioniert! Danke!

Wobei alles einheitlich zu haben, wäre mir schon irgendwie lieber ... Wie kann ich xterm mit "Select tot Clipboard" eingeschaltet starten?

----------

## SarahS93

Wie kann ich mir Größe und Position im KDE4 von einem Fenster anzeigen lassen?

----------

## Christian99

Systemeinstellungen->Fensterverhalten->Fensterverhalten->Verschieben->"Bei Verschieben und Größenänderungen die Geometrie anzeigen" auswählen, z.b.

----------

## musv

 *SarahS93 wrote:*   

> xterm-boarderless

 

Gibt's bei mir irgendwie nicht. Ist das 'n extra Paket, Use-Flag?

 *SarahS93 wrote:*   

> Hehe, toll, mausrad drücken im kwite - wer denkt denn auch an sowas, funktioniert! Danke!
> 
> Wobei alles einheitlich zu haben, wäre mir schon irgendwie lieber 

 

Nun ja, kommt drauf an, was man als "einheitlich" definiert:

Copy durch Markieren und Paste über die mittlere Maustaste ist das Unix-Standard-Copy+Paste. Das gab's schon lange vor Ctrl-C / Ctrl-V. Anstatt der mittleren Maustaste kannst du auch Shift + Einfügen drücken. Ist "eigentlich" auch logisch, wozu sollte es sonst eine "Einfügen"-Taste geben. Und es funktioniert eigentlich auch überall. D.h. du kannst auch im KWrite markieren und das dann in die Konsole oder ins LibreOffice einfügen.

Hier gibt's 'ne schöne Erklärung, wie sich was entwickelt hat.

http://superuser.com/questions/421463/why-does-ctrl-v-notpaste-in-bash-linux-shell

----------

## py-ro

@musv Hättest den Thread gelesen  :Wink: 

----------

## SarahS93

Hehe,

so gibts in meinem sys das xterm-boarderless im kde4

su

cd /usr/bin

ln -s xterm xterm-boarderless 

(-;

-

Die Option die infos zu bekommen wo und wie gross welches Fenster sitzt oder hängt ist mal echt klasse!

----------

## musv

 *py-ro wrote:*   

> @musv Hättest den Thread gelesen 

 

Hab noch mal drübergelesen. Ich glaub, ich hab's jetzt geschnallt. Gute Idee. 

Btw. die Geometriedatenanzeige gibt's eigentlich bei jedem Windowmanager. Ich nutz e16. Da weiß ich gar nicht, wie ich das abstellen könnte.

----------

## Yamakuzure

Nur mal eine grundsätzliche Frage:

Du benutzt KDE und limitierst dich auf das Mini-Gelumpe xterm statt konsole zu benutzen? Warum? KDE konsole + yakuake. Unschlagbar.

----------

## mv

 *Yamakuzure wrote:*   

> Mini-Gelumpe xterm statt konsole

 

 :Question: 

Auf den Umgebungen, in denen ich gezwungen bin, KDE oder Gnome zu benutzen, ist das erste, was ich mache, die jeweiligen Schmalspur-Klone von xterm, xdvi, emacs, firefox wieder durch die vollwertigen Programme (mit vernünftiger Tastatursteuerung und ohne abgeschnittene Features) zu ersetzen. Dass die Fenster ggf. leicht anders als das "Theme" aussehen, nehme ich dafür gern in Kauf: Das scheint ja das einzige zu sein, was die Macher von Desktopumgebungen unter "Desktop-Integration" verstehen:

"Desktop-Integration" wird immer als Grund für die abgespeckten Nachbauten genannt; außer der Anpassung der Optik an irgendein "Theme" (also runde statt eckige Knöpfe und störendes Überschreiben der von mir anders gewünschten Farbe, weil die Macher des "Themes" meine Farbwahl anscheinend für unpassend für das Theme halten) habe ich davon noch nie etwas mitbekommen. Wenn es echte Gründe gibt, die ich nur nicht kenne, lasse ich mich aber gerne überzeugen...

----------

## py-ro

@mv was kann den konsole weniger als xterm?

----------

## mv

 *py-ro wrote:*   

> @mv was kann den konsole weniger als xterm?

 

Es liegt lange zurück, dass ich es benutzt hatte. Die kleinen Ärgernisse hatten sich gehäuft, aber das meiste habe ich inzwischen natürlich wieder vergessen. Wenn ich mich richtige erinnere, gab es keine Möglichkeit, die Puffergröße einzustellen (gab es überhaupt einen Puffer? Zumindest konnte man nicht mit Tasten vernünftig zurückblättern - sagen wir, die letzten 10000 Zeilen); bei verschiedenen Kombinationen mit screen/tmux/remote-Shells gab es verschiedene Probleme mit falschen Darstellungen, was mit Inkompatiblitäten der TERM-Interpretation zusammenhing; viele Tastenkombinationen (Funktionstasten, Ctrl-... u.ä.) wurden oft abgefangen statt weitergeleitet: einen remote-Emacs (mit einer eigenen "wilden" Tastaturbelegung) in einem kterm zu bedienen, war dadurch ein Ding der Unmöglichkeit; dass gewisse Farbsequenzen ignoriert oder gemäß irgendwelchen "Themes" interpretiert werden, schrieb ich ja schon; mit der Schriftartwahl, Setzen von Hintergrund- und Cursorfarbe war ich auch nicht zufrieden oder habe es nicht bequem auf allen Systemen als Default hinbekommen - genau kann ich mich nicht mehr erinnern: Das ist halt der generelle Nachteil von GUI-Gefummel; statt eine Datei mit wohldokumentieren X-Resources einmal zu speichern und dann auf allen gewünschten Systemen (system- oder nutzerweit) zu verteilen, muss man auf jedem System erneut herumfummeln.

Die Frage muss umgekehrt lauten: Selbst wenn ich mir die ganze Arbeit mit der Konfiguration gemacht hätte, und selbst wenn es einen zufriedenstellenden Puffer gäbe und man den wie gewünscht konfigurieren könnte, und selbst wenn es die Probleme mit Farben und Schritftart und generellem Festlegen der Defaults nicht gäbe und irgendwelche anderen Inkompatibilitäten -  was bringt das Ganze? Dann hat man das, was man bei xterm schon von Anfang an hatte: Mit viel Aufwand kam man auf eine schlechter funktionierende Nachahmung!

In der nächsten KDE-Version, wenn es nur noch das neue hippe "Chrome-duper-Theme" gibt und das längst veraltete "DuperII+-Theme" "endlich herausgeworfen" wurde, kann man natürlich gerade wieder von vorne anfangen - auch schon zweimal miterlebt. Mein xterm hingegen sieht immer noch so aus wie es soll (solange ich KDE abgewöhnen kann, auch nicht-KDE-Anwendungen das Theme aufzuzwingen, was bislang glücklicherweise immer noch irgendwie ging).

----------

## py-ro

Das muss aber verdammt lange her sein, alles davon geht ohne Probleme und ich hab Konsole für mindestens 7 Jahre jetzt straight im 24/7 Einsatz.

----------

## franzf

Desktop-Integration bedeutet für mich auch Dateidialog - und da hat KDE noch immer die Nase vorne. Allein schon wegen konsistentem Single-Click (den man bei GTK selbst nach jahrealtem Bugreport mit regelmäßigen Patch-Updates nicht bekommt).

Was mMn. aber oft gegen DE-integrierte Anwendungen spricht ist der "single-application"-Ansatz: Egal wie oft man das binary ausführt, es geht (im besten Fall) nur ein neues Fenster auf, es gibt allerdings nur eine einzige Instanz. Dumm wenn dann ein Bug zum Hänger oder Absturz fürt - dann sind nämlich alle "Instanzen" für'n Popo... Und genau an so einen Bug erinner ich mich bei konsole: Es kam zu Hängern und teilweise auch zu Abstürzen. Für nen Admin natürlich ganz toll, wenn er dutzende/hunderte Fenster offen hat, teilweise zeitintensive Anwendungen noch laufen (wissenschaftliche Berechnungen, lange Kompilation, ...)...

Bei libreoffice ist es dann so, dass ein einziger offener (Datei)Dialog sämtliche anderen Fenster blockiert. Hab ich bei nem Kollegen mehrfach mit ansehen können: Will eine Datei speichern, vorher aber noch schnell was nachsehen (z.B. in dolphin, wo er jetzt genau hinspeichern will, weil da schon andere dazugehörige Dateien liegen). Dazu wird das libreoffice-Fenster minimiert. Natürlich wird das vergessen - andere Aufgaben, Störung, Pinkelpause, ... - und ein neues LO-Fenster reagiert dann plötzlich nicht mehr auf Eingaben - Jippie!

Und mMn. trägt der Fenster- und Programmstyle zur Benutzbarkeit bei, denn es ist letztlich der style der die Differenzierung einzelner Elemente (Button, Label, Input, ...) verantwortet. Vor allem unbedarfte Nutzer tun sich da oft unnötig schwer.

----------

## mv

 *py-ro wrote:*   

> Das muss aber verdammt lange her sein

 

So lange nicht. Ich hatte es mindestens einmal mit KDE, KDE2, KDE3, und KDE4 versucht, jeweils ohne merkliche Verbesserung. Der letzte Versuch liegt also definitiv nicht länger als 2 Jahre zurück, und ich glaube nicht, dass sich da gerade so viel an kterm getan hat: Prioritäten bei KDE hatte eindeutig der Nepomuk/Akondadi/Soprano-Unfug, der ja jetzt anscheinend schon durch was viel Hipperes ersetzt wurde, was m.E. gerade die Nachteile dieses Systems verstärkt. Aus Erfahrung kann ich dazu allerdings nichts sagen, da ich auf meinen eigenen Rechnern KDE mit der damaligen Elimination des symtantic-desktop-USE-flags entsorgt hatte, und Rechner, die ich aufgezwungen bekomme, auch kein KDE mehr haben. (Zufall?)

----------

## mv

 *franzf wrote:*   

> Desktop-Integration bedeutet für mich auch Dateidialog

 

Die Details kenne ich nicht, aber ist das nicht eher das Toolkit (gtk bzw. qt)?

Einen Zusammenhang mit kterm/konsole/Gnome Terminal sehe ich diesbezüglich gar nicht, denn wozu sollte man da einen Dateidialog haben?

 *Quote:*   

> Für nen Admin natürlich ganz toll, wenn er dutzende/hunderte Fenster offen hat, teilweise zeitintensive Anwendungen noch laufen (wissenschaftliche Berechnungen, lange Kompilation, ...)...

 

Du hast kein tmux/screen? OK, das könnte natürlich theoretisch ähnliche Probleme haben...

 *Quote:*   

> Und mMn. trägt der Fenster- und Programmstyle zur Benutzbarkeit bei, denn es ist letztlich der style der die Differenzierung einzelner Elemente (Button, Label, Input, ...) verantwortet. Vor allem unbedarfte Nutzer tun sich da oft unnötig schwer.

 

Kein Grund, einem Terminal Einheitsfarben aufzuzwingen. Und ob irgendein Button jetzt rund oder eckig ist - selbst bei Neunutzern, ist die Erkkennung des Buttons als Button nicht die Schwierigkeit, wenn sie generelll einmal das Konzept "Button" gesehen haben; so funktioniert das Gehirn: Ein Tisch ist ein Tisch, solange er nur halbwegs wie ein Tisch aussieht. M.E. werden da viele laienhafte und nicht fundierte Usability-Konzepte benutzt; und diese schlagen auf die echte Usability durch, die Benutzer mit mehr Erfahrung behindert.

----------

## franzf

 *mv wrote:*   

> Die Details kenne ich nicht, aber ist das nicht eher das Toolkit (gtk bzw. qt)?

 

Jein. Qt ist DE-unabhängig, die haben ihren eigenen Dateidialog. Allerdings gibt es einen Handler, den man setzen kann um nen eigenen Dialog zu starten. AFAIK passiert das automatisch, wenn Qt erkennt, dass es in einer KDE-Umgebung läuft (oder unter Windows).

Für GTK trifft das nicht zu, denn das wird direkt von Gnome (ver)entwickelt. Aus aktuellem Anlass:

https://bugzilla.gnome.org/show_bug.cgi?id=722211

(Da sieht man auch, wie einfach es ist ganze problemspezifische Diskussionen abzuwürgen...)

 *Quote:*   

> Einen Zusammenhang mit kterm/konsole/Gnome Terminal sehe ich diesbezüglich gar nicht, denn wozu sollte man da einen Dateidialog haben?

 

kterm == konsole? Ja, nen Dateidialog braucht man da nicht. Aber du hast das allgemeine DE-Integrations-Tema angeschnitten und browser und Texteditor angeführt - da spielt ein Dateidialog sehr wohl eine Rolle.

 *Quote:*   

> Du hast kein tmux/screen? OK, das könnte natürlich theoretisch ähnliche Probleme haben...

 

ICH verwende eh kein kde mehr (ebenfalls seit der zugegebenermaßen nur kurzen Episode des aufgezwungenen semantic-desktop) - urxvt+tmux+firefox(vimperator)+awesome-wm.

Allerdings bringt dir tmux herzlich wenig, wenn die GUI (=konsole) einfriert - da bleibt nur konsole abzuschießen und zig tmux sessions im passenden konsolen-Fenster auf passendem Desktop wiederherzustellen.

 *Quote:*   

> Kein Grund, einem Terminal Einheitsfarben aufzuzwingen. Und ob irgendein Button jetzt rund oder eckig ist - selbst bei Neunutzern, ist die Erkkennung des Buttons als Button nicht die Schwierigkeit, wenn sie generelll einmal das Konzept "Button" gesehen haben; so funktioniert das Gehirn: Ein Tisch ist ein Tisch, solange er nur halbwegs wie ein Tisch aussieht. M.E. werden da viele laienhafte und nicht fundierte Usability-Konzepte benutzt; und diese schlagen auf die echte Usability durch, die Benutzer mit mehr Erfahrung behindert.

 

Auch hier: die allgemeine DE-Integration hast du angeschnitten  :Wink: 

Und ich habe Episoden erlebt, in denen ein Button nur schwer von einem Lineedit unterscheidbar war, da Style und Colorscheme die RELATIV ähnlich aussehen ließen. Ist aber eigentlich auch egal, denn Styles kann man ändern und mit viel Durchhaltevermögen Toolkit-übergreifend relativ einheitliche Lösungen fabrizieren (was mit dem angesprochenen Filedialog eben gerade nicht geht).

 *Quote:*   

> Prioritäten bei KDE hatte eindeutig der Nepomuk/Akondadi/Soprano-Unfug, der ja jetzt anscheinend schon durch was viel Hipperes ersetzt wurde, was m.E. gerade die Nachteile dieses Systems verstärkt.

 

Ich darf bei einem Bekannten noch ein kde-System administrieren. Einfach weil es mich interessiert hat habe ich die default-Einstellungen für semantic-desktop übernommen (alle Vorkommen aus USE streichen, passendes KDE Profil ist eh schon gesetzt). Update von 4.12.5 direkt auf 4.13.1 (baloo in .0 hatte wohl einige Startschwierigkeiten) und ich muss sagen man merkt nichts davon, und es funktioniert super. Vor allem das Panel im Dolphin mit "Kürzlich aufgerufene" finde ich selber praktisch. Verwenden werde ich kade aber weiterhin nicht  :Wink: 

----------

## Yamakuzure

mv, sei mit bitte nicht böse, aber Konsole verhält sich zu xterm ungefähr so wie vim zu nano. Funktionieren beide, aber Ersteres kann deutlich mehr. Wenn man das "mehr" benötigt, ist die Wahl einfach. (Ich verwende übrigens meistens nano für einfache Arbeiten, da ich das "mehr" in vim nicht benötige.  :Wink: )

Ich habe mal ein wenig "gegoogelt", da meine obige Aussage natürlich reichlich subjektiv ist. (Klar.) Und das hier gefunden:

https://blogs.kde.org/2005/05/07/psssst-kde-konsole-more-efficient-xterm

Auf allen meinen Maschinen läuft zudem kde-misc/yakuake, darauf will ich garnicht mehr verzichten. Von den Tabs und der Möglichkeit Zeichensätze umzuschalten und individuelle Sitzungsprofile, sowie unlimitierten Zeilenpuffer zu verwenden mal ganz zu schweigen.

Ich suche bei xterm bis heute die Möglichkeit mehrere Sitzungen in Tabs zu haben...

----------

## mv

 *Quote:*   

> aber Ersteres kann deutlich mehr

 

Außer Tabs kenne ich kein Beispiel. Auch auf dem Link, den Du genannt hast, steht kein Beispiel dafür.

 *Quote:*   

> Von den Tabs und der Möglichkeit Zeichensätze umzuschalten und individuelle Sitzungsprofile, sowie unlimitierten Zeilenpuffer

 

Gewisse Limits bei den Puffern sind sinnvoll, um im Falle einer Fehlbedienung nicht das System "tot" zu schießen. Bei xterm habe ich eben per meinen Einstellungen, Puffer, die für alle relevanten Zwecke groß genug sind. Zeichensätze umschalten ist kein Thema bei xterm. Nicht, dass ich das jemals benutzt hätte: Eine gut lesbare Schrift in vernünftiger Größe reicht doch. Aber theoretisch (wie, gesagt: praktisch noch niemals benutzt) habe ich auch andere Schriftgrößen eingestellt, auf die ich bei Bedarf wechseln könnte.

"Individuelle Sitzungsprofile" - keine Ahnung, wozu man das brauchen soll, denn meine Einstellungen für xterm sind für alle Zwecke tauglich: Wozu sollte ich in speziellen Modi grundsätzlich riesige oder nichtlesbare Schriften haben wollen o.ä. - eine gut lesbare Schrift tut es in allen Situationen. Bleibt wieder ein einziges Feature: Tabs.

 *Quote:*   

> Ich suche bei xterm bis heute die Möglichkeit mehrere Sitzungen in Tabs zu haben...

 

Das Feature nennt sich "tmux" oder "screen" und funktioniert auf allen Terminals. Für Tabs als Terminal-Feature gibt es einfach keinen Bedarf. Wichtiger sind Puffergröße, Scrollback-Möglichkeiten usw. - OK, Deinem Link zufolge kann man mit viel Arbeit anscheinend einen xterm-Kompatibilitätsmodus bei kterm erreichen. Wozu soll ich mir die Mühe machen, wenn ich das Original nehmen kann, das dann auch von Uralt-Systemen, auf die ich mich manchmal einlogge, perfekt unterstützt wird?

Edit: Im Moment ist die Diskussion sowieso weitgehend akademisch, da ich KDE aus verschiedenen Gründen entsorgt habe und daher nicht verifizieren kann, was sich ggf. in jüngerer Zeit geändert hat. Die Abhängigkeit zum Monster KDE(libs) ist natürlich noch ein prinzipieller Grund, der gegen kterm spricht... nicht so sehr aus weltanschaulichen Gründen, sondern weil man kterm dadurch auf vielen Rechnern nicht findet. Einen X Rechner ohne xterm (oder leicht nachinstallierbares xterm) habe ich noch nie gesehen.

----------

