Keyboard-Events für das Window-Resizing an ein Terminal Fenster unter Linux senden
-
Hallo allerseits,
ich will, dass gleich beim Start einer Linux Terminal Anwendung zwei Sachen geschehen.
Und zwar,- Dass die Fontsize im Terminalfenster verkleinert wird.
- Dass das Terminalfenster vergrößert wird.
Nun wäre meine Frage an euch, wie ich es schaffe, die entsprechenden Keyboard-Events für das Window-Resizing an das Fenster zu senden.
Es wäre gut, wenn ich diesem Befehl gleich in das C++ Skript integrieren könnte.
Danke im voraus!
Mit freundlichen Grüßen DUSKOR
-
Ich bezweifle, dass das möglich ist.
-
Kleinkarierte Antwort:
Mit einem C++ Skript geht das sicher nicht, da C++ keine Skriptsprache ist, sondern übersetzt werden muss.Ernsthafte Antwort, allerdings nur Vermutungen, da ich mich mit Linux so garnicht auskenne:
Gibt es unter Linux keine Möglichkeit herauszufinden, was das zugehörige Fenster zu einem Prozess ist? Kennt ein Prozess seinen Parent-Prozess? Also kann man sich in der Prozesshierachie so lange nach oben hangeln, bis man ein Fenster findet? Damit hätte man zumindest das Fenster und kann es maximieren. Ob und wie man die Fontgröße ändern kann... keine Ahnung, vllt weiß jemand anderes mehr.
-
@DocShoe sagte in Keyboard-Events für das Window-Resizing an ein Terminal Fenster unter Linux senden:
Gibt es unter Linux keine Möglichkeit herauszufinden, was das zugehörige Fenster zu einem Prozess ist? Kennt ein Prozess seinen Parent-Prozess? Also kann man sich in der Prozesshierachie so lange nach oben hangeln, bis man ein Fenster findet? Damit hätte man zumindest das Fenster und kann es maximieren. Ob und wie man die Fontgröße ändern kann... keine Ahnung, vllt weiß jemand anderes mehr.
Die zugehörigen "Fenster" sind die TTY's - Unix terminals. Jede Anwendung hat mindestens ein zugehöriges TTY, ohne dass wären cout und cerr nicht möglich. Ein cin, also was für die Eingabe zu haben, ist ein anderes Thema (Stichwort: terminal emulation). Jeder Prozess hat ein Parent, es ist ein Baum mit init in der Wurzel (und der Herr und Meister von init ist der Kernel). Die Prozesshierarchie, die man durchgehen muss, ist das procps, die meisten kennen seine Dateirepräsentation
/proc. Die Möglichkeit sich darin auszutoben ist in der Regel durch diverse Rechte beschränkt. Aber was hier gemacht werden soll, geht tief in die Xlib/xcb Programmierung, an der selbst die Xlib Entwickler öfter scheitern. Ein guter Startpunkt wäre hier das alte Xlib Tutorial, aber das wird eventuell nicht reichen. Wir reden hier von einer Funktionalität, die von einem Windowmanager abgedeckt wird. Man wird sich also mit der Implementierung von X11 Windowmanagern beschäftigen müssen, und das ist nicht nur extrem schweres Zeug, es macht auch obendrein wenig Spaß. 
-
@VLSI_Akiko sagte in Keyboard-Events für das Window-Resizing an ein Terminal Fenster unter Linux senden:
Die zugehörigen "Fenster" sind die TTY's - Unix terminals. Jede Anwendung hat mindestens ein zugehöriges TTY, ohne dass wären cout und cerr nicht möglich.
Nein, das muss nicht der Fall sein. Es gibt eine ganze Klassen von Anwendungen bei der das nicht der Fall ist: daemons. Ein daemon ist explizit von jedem Terminal entkoppelt. IO geht dann nur noch in Dateien und zum Steuerung eines daemons muss man explizit Signals verwenden. Damit das dann funktioniert muss man Signal Handler schreiben.
Anwendungen haben üblicherweise keinerlei Kontrolle über das Terminal. Das ergab früher auch keinerlei Sinn, weil das Terminal eine spezielle Hardware war, die man auch nicht per Programmcode in einen anderen Hardwaremodus schalten konnte. Bei einem Softwareterminal muss man die proprietären Protokolle des GUI Toolkits benutzen. Da würde ich aktuell auf DBus tippen.
Allgemein wenn das Terminal programmieren will, sollte man die ncurses Library nutzen.
-
@john-0 sagte in Keyboard-Events für das Window-Resizing an ein Terminal Fenster unter Linux senden:
Nein, das muss nicht der Fall sein. Es gibt eine ganze Klassen von Anwendungen bei der das nicht der Fall ist: daemons. Ein daemon ist explizit von jedem Terminal entkoppelt. IO geht dann nur noch in Dateien und zum Steuerung eines daemons muss man explizit Signals verwenden. Damit das dann funktioniert muss man Signal Handler schreiben.
Ja, ich gehe an dere Stelle mal von dem Normalfall aus. Daemons sind da ein Spezialfall, schon allein wegen dem double-fork.
Anwendungen haben üblicherweise keinerlei Kontrolle über das Terminal. Das ergab früher auch keinerlei Sinn, weil das Terminal eine spezielle Hardware war, die man auch nicht per Programmcode in einen anderen Hardwaremodus schalten konnte. Bei einem Softwareterminal muss man die proprietären Protokolle des GUI Toolkits benutzen. Da würde ich aktuell auf DBus tippen.
Ja, das meinte ich. Als normaler User im System hat man da nicht viele Möglichkeiten. Das auch aus gutem Grund, mit derartigen Sachen kann man viel Blödsinn anstellen.
Allgemein wenn das Terminal programmieren will, sollte man die ncurses Library nutzen.
Naja, oder man verwendet eben ANSI Sequenzen. ncurses ist dagegen schon fast zu einfach und zieht es eben diverse Abhängigkeiten mit rein, wo ich mir nicht ganz sicher bin, ob man das haben will. Unicode ist dann auch etwas nervig.
