GUI für Terminal Programm entwickeln

J

Jens Ko.

Aktives Mitglied
Thread Starter
Dabei seit
31.01.2005
Beiträge
136
Reaktionspunkte
0
Hi zusammen,

hat schon mal wer versucht eine GUI für ein Terminal Programm zu entickeln?
Kennt wer ein Tutorial oder eine Seite, die das beschreibt?

Stelle mir das so vor, dass das Programm ausgeführt wird und die Ausgaben
vom Programm aufgefangen werden und dann auf einer GUI angezeigt werden.

nutzen will ich alle möglichen Terminal Befehle / Programme wie dir, ftp usw...

Danke und Grüße
Jens
 
Willst Du eine "GUI" im Terminal (ncurses) oder ein normales GUI-Programm, das ein Terminal-App fernsteuert?
 
also mich persönlich interessiert beides...... brennend.
 
2. Ist ein "normales" Cocoa-Programm (siehe developer.apple.com) - ersteres würd ich nicht machen, weils eh kaum einer nutzen wird...
 
Hi,

danke erstmal für die Antworten!
Also mich pers. würde eher 2. interessieren. Leider habe ich im Moment noch keinen rechten Ansatz, wie ich die Ein/Ausgaben des Programms in mein Programm rein/rausbekomme. Denn eigentlich läuft da ja ein Programm, was seine Ausgaben auf dem Screen macht.
Kann man das irgendwie "mitbekommen"? Unter Linux gibt es ja die Pipes, bei den man die Ausgaben in eine Datei schreiben kann.
Aber so der wahre Bringer find ich das nicht, über text Dateien das zu machen. Mein Problem ist, wie ich also mit meinem Programm mit dem
Terminal Programm interagiere.

developer.apple.de ist denke ich kein schlechter Anlauf, aber das richtige Dokument habe ich noch nicht gefunden.
 
das Terminal ist ein extrem flexibles Werkzeug zum Arbeiten mit der "Everything is a file-Philosophie von UNIX. Nur selten wird jemand ein einfaches Kommando eingeben und die Ausgabe betrachten ( wie ls oder cd), häufig sind es mehrere verkettete Befehle, die Ihre Eingaben per Piping beziehen. Die Vorgänge sind zumeist so individuell, daß sich Skripte (noch) nicht lohnen. Wie soll man sowas sinnvoll in eine GUI fassen? Die Stärke des Terminals ist gerade, daß es KEINE GUI ist - auch und gerade deswegen hat es als xterm in allen UNIX-GUIs überlebt.
 
Also Quasi ein Programm, was mit dem Terminal kommuniziert?
Und Buttons für die verschiedenen Befehle?

Pardon, ich kann mir darunter nichts vorstellen, und der Sinn erschließt sich mir nicht ganz...

Weil, das Terminal "lebt" ja quasi davon, dass es keine GUI hat, oder?
die einzige, meines erachtens nach, sinnvolle Einsetzung wäre es, bestimmte Funktionen zu sperren, also alles mögliche, was "zerstörerisch" ist...

erklärts mir bitte, weil uninterssant ist es nicht.

gruß
Lukas
 
Schau dich doch mal bei sourceforge, cocoaforge und osx.freshmeat.net nach Programmen um die Cocoa-Wrapper für Terminal-Programme sind. Auf Anhieb fallen mir da MPlayerOSX, HandBrake, Cocoawget und SimpleWget ein.

Das allseits beliebte ffmpegX macht auch nichts anderes. Ist allerdings nicht OpenSource. An dem Beispiel sieht man aber deutlich wozu das gut sein kann: Eine GUI mit 5 Buttons bedient sich leichter als zwei Terminalprogramme mit 2 man-Pages und hundert Flags und Optionen.
 
Ich sehe den Nutzen schon. Onyx und Konsorten sind ein gutes Beispiel dafür. Die machen viele Befehle, die man sonst mühevoll ins Terminal einhacken muß per GUI ausführbar, kann bestimmte Parameter setzen etc. auch die man-pages können so viel besser visualisiert werden und sind so gleich viel handelbarer. Klar kann man nicht alles in einer GUI abbilden, aber vieles sehr wohl.
Deswegen, Terminal, je weniger desto besser. :cool:
Das Terminal ist halt ein überbleibsel aus der Vergangenheit und viele mögen sich halt nicht vom gewohnten trennen. (Siehe die ganzen Threads bzgl. OS9 vs. OSX) ;)
 
pdr2002 schrieb:
Das Terminal ist halt ein überbleibsel aus der Vergangenheit und viele mögen sich halt nicht vom gewohnten trennen

Einspruch Euer Ehren :)

Als Wrapper für bestimmte Funktionen hat es schon immer System-Calls gegeben! Da bin ich auch absolut dafür, warum Anwender mit dem Terminal drangsalieren.

Für mich als Admin stellt es einen gigantischen Werkzeugkasten bereit, den schlicht keine GUI komplett kapseln kann - soll sie bedienbar bleiben. Das Terminal ist beileibe kein Relikt, nur braucht es längst nicht mehr jeder User ( und das ist sehr gut so). Als Admin habe ich permanent 5-8 Terminals von verschiedenen Rechnnern offen, kann Probleme diagnostizieren und zumeist auch beheben. Nimm UNIX die bash weg und es ist weitaus schlechter beherrschbar als jedes Windows XP!
 
lach, ich hoffe hier nicht eine Grundsatz Diskussion über Terminal Befehle / GUI loszutreten. Das wäre wirklich nicht meine Absicht.

Ganz im Gegenteil (nutze das Terminal auch oft), ich kenne ein paar unix Programme, wie zB. rsync (darum geht es ganz konkret) die schon äußerst genial sind.
Jedoch müssen (können) ja einige Parameter übergeben werden, dass das Programm das macht, was ich will.

Äußerst interessant sind hier zB. die Ausgaben der zu syncronisierenden Dateien. Ich möchte einfach die Funktion des rsync nutzen um Dateien
zu syncronisieren, das aber mit einem Programm mit GUI und nicht auf Commandline Ebene.

Das mit dem "ls" Befehl wäre nur mal ein Beispiel um ein Gefühl zu bekommen, wie man mit den Commandline Befehlen umgehen muss. (sinnvoll oder nicht bleibt hier sicher dahingestellt, es geht eher um den "Lerneffekt")

@Jokkel, schau ich mir mal an, danke für den Tip
 
Jens Ko. schrieb:
Ganz im Gegenteil, ich kenne ein paar unix Programme, wie zB. rsync
(darum geht es ganz konkret) die schon äußerst genial sind.
Jedoch müssen (können) ja einige Parameter übergeben werden, dass das Programm das macht, was ich will.

Äußerst interessant sind hier zB. die Ausgaben der zu syncronisierenden Dateien. Ich möchte einfach die Funktion des rsync nutzen um Dateien
zu syncronisieren, das aber mit einem Programm mit GUI und nicht auf Commandline Ebene.

Genau das ist ein Wrapper-Programm und macht nat. Sinn. Terminal-Befehle werden meist mit Funktionen a la system oder execute ausgeführt ( die Anwendungsprogrammierer hier wissen das sicher genau). Die Ausgabe solcher Programme gehen dann entweder nach stdout oder in eine Log-Datei. Beides läßt sich bequem in das eigene Programm umlenken. Ersteres per Piping (z.B.) und letzteres mit dem Terminal-Befehl tail -f

tail -f /var/log/system.log gibt endlos alle angefügten Zeilen dieser Log-Datei wieder, bis ein Abbruch erzwungen wird!
 
Super, die Diskussion hat mich denke ich wirklich weitergebracht. Klingt nach genau dem, was ich suche!

Schaue mir das Wrapper Thema mal intensiver an! (wie was neues gelernt, kannte den Begriff garnicht!)

Danke Euch mal! (neue und zusätzliche Beiträge zu dem Thema sind natürlich mehr als willkommen!!)
(manchmal hätte ich gerne Eure Lesezeichen, da gibt es bestimmt noch 1000e super interessante Themen))

@Nuke, genausowas habe ich gesucht!

Grüße Jens
 
Zuletzt bearbeitet:
wegus schrieb:
Einspruch Euer Ehren :)

Als Wrapper für bestimmte Funktionen hat es schon immer System-Calls gegeben! Da bin ich auch absolut dafür, warum Anwender mit dem Terminal drangsalieren.
Und? sind die armen Admins keine Menschen, die man unbedingt mit einem Terminal drangsalieren muß? Ich denke nicht. ;)
wegus schrieb:
Für mich als Admin stellt es einen gigantischen Werkzeugkasten bereit, den schlicht keine GUI komplett kapseln kann - soll sie bedienbar bleiben. Das Terminal ist beileibe kein Relikt, nur braucht es längst nicht mehr jeder User ( und das ist sehr gut so). Als Admin habe ich permanent 5-8 Terminals von verschiedenen Rechnnern offen, kann Probleme diagnostizieren und zumeist auch beheben. Nimm UNIX die bash weg und es ist weitaus schlechter beherrschbar als jedes Windows XP!
Hm, eigentlich ist die bash doch auch nur eine (armselige) GUI mit der man auf bestimmte Befehle zugreift. Ich behaupte mal, daß es keinen zwingenden Grund gibt, daß Du mehrere Terminals gleichzeitig offen hast, sondern daß es reine Gewohnheit ist. :p
Wie gesagt, ich weiß um die Bedeutug der ganzen Programme auf die man zugreift, mir geht es halt um das wie.
Ich bin für das Monitoring für etwa 1.500 Server (Anzahl ständig steigend)verantworlich (gemischt Windows, das meiste, Unix und Großrechner (VMS), etc). Wenn ich einen Server genauer analysieren will, nutze ich eine GUI in der ich alle Informatonen visuell im Blick habe, wo ich aber auch eingreifen kann, wie Dienste starten, stoppen, etc, halt alles was das Herz begehrt. In der heutigen Zeit sind die Netzwerke schnell genug, so daß ein flüssiges Arbeiten möglich ist.
Das Terminal brauche eigentlich nur für einige wenige Diagnosetools für die es keine GUI gibt und ich finde es graussam, da die Eingabe der ganzen Parameter, fehlernafällig. Muß ich so ein Tool häufiger nutzen, kann ich mir unter Windows schnell eine, für mich einfache GUI, zusammen stellen, was mir dann die Arbeit sehr erleichtert. Diese Möglichkeit gibt es unter Unix leider nicht in der Form. :cool:
 
pdr2002 schrieb:
daß Du mehrere Terminals gleichzeitig offen hast, sondern daß es reine Gewohnheit ist

jedes Terminal gehört zu einem Server ;)


pdr2002 schrieb:
Ich bin für das Monitoring für etwa 1.500 Server (Anzahl ständig steigend)verantworlich (gemischt Windows, das meiste, Unix und Großrechner (VMS), etc). Wenn ich einen Server genauer analysieren will, nutze ich eine GUI in der ich alle Informatonen visuell im Blick habe, wo ich aber auch eingreifen kann,

Kann es sein, daß Du da ein leicht anderes Budget hast? Mehr als Nagios, für derzeit 49 wichtige Dienste, ist bei uns nicht drinnen!

pdr2002 schrieb:
uß ich so ein Tool häufiger nutzen, kann ich mir unter Windows schnell eine, für mich einfache GUI, zusammen stellen, was mir dann die Arbeit sehr erleichtert. Diese Möglichkeit gibt es unter Unix leider nicht in der Form.

VB .NET ? IDEs zum zusammenclicken von Applikationen gibt es doch in fast jeder Sprache und sei es, wie bei heterogenen Umgebungen angeraten, Java!
 
wegus schrieb:
jedes Terminal gehört zu einem Server ;)
Das hatte ich mir schon gedacht. :D Ich muß ganz selten direkt auf die Server und meistens, wenn dann über eine RDP-Session.

wegus schrieb:
Kann es sein, daß Du da ein leicht anderes Budget hast? Mehr als Nagios, für derzeit 49 wichtige Dienste, ist bei uns nicht drinnen!
Nur ein kleines bißchen (müssen ja noch die 3 MS OnSite-Mitarbeier bezahlen) ;)


wegus schrieb:
VB .NET ? IDEs zum zusammenclicken von Applikationen gibt es doch in fast jeder Sprache und sei es, wie bei heterogenen Umgebungen angeraten, Java!
Oh Gott bewahre, Basic auf meinem guten alten C64 war genug. Nein ich nutze C#.Net und nein es ist kein VB mit anderer Syntax. ;) Java ist nichts für mich, auch wenn man damit jetzt auch schon GUIs erstellen kann, fällt es mir mit C# deutlich einfacher und sooviel Zeit habe ich nun auch nicht. :D
 
naja ist ja alles letztlich .NET und sicher auch ganz nett, nur leider letztlich Windows-only und da sind sie wieder die Probleme...
 
wegus schrieb:
naja ist ja alles letztlich .NET und sicher auch ganz nett, nur leider letztlich Windows-only und da sind sie wieder die Probleme...
Cocoa ist auch MacOS only...
 
StruppiMac schrieb:
Cocoa ist auch MacOS only...


weswegen ich ja auch von Java in dem von pdr2002 erwähnten Kontext sprach ;)
 
Zurück
Oben Unten