Gast
#3649050
Mahlzeit, ich arbeite zur Zeit daheim an einem Kommandozeilentool, was jetzt schon recht umfangreich ist. Das Tool ist interaktiv, d.h. es stellt einen Prompt zur Verfügung. Der Nutzer kann durch Eingabe von Befehlen und Parametern bestimmte Funktionen abrufen. Kann man wohl vergleichen mit dem gdb im cli-Modus. Nun würde ich dieses Tool gerne um eine GUI erweitern. Im Linux/Unix Umfeld wird man ja immer derart geimpft, Front- und Backend zu trennen. Dementsprechend überlege ich nun auch, diese Gui als eigenständiges Programm zu implementieren, was eben die Funktionalität meines Tools benutzt. Wie sollte ich da Vorgehen? Interprozesskommunikation mittels Pipes? Sockets? Der gdb nutzt ja Tcp/Ip, auch wenn Server und Client auf der selben Maschine laufen. Wär das auch für mich ein Ansatz? Wie sollte die Kommunikation zwischen den Prozessen ablaufen? ASCII-Interface? Das ist ja auch etwas, was einem im Unix-Umfeld immer eingetrichtert wird. Vorteil den ich bei einem ASCII-Interface über Sockets/Pipes sehe: die Kommandos die normal der Nutzer eingibt werden von der Gui generiert. Der Output des Tools wird von der Gui geparst und visualisiert. Nur wenige Änderungen am Tool nötig, da es diesem relativ egal ist ob die Kommands aus einem Socket oder aus cin kommen. Sollte ich bei diesem Ansatz ein Protokoll zur Kommunikation nutzen oder wirklich nur den Output parsen? Eine andere Möglichkeit wäre die Gui direkt ins Tool zu integrieren. Weiß nicht ob das designtechnisch besser ist. Der Insight-Debugger machts ja so. Im Gegensatz zum ddd "benutzt" Insight nicht den gdb, sondern hat diesen direkt integriert. So würde ich mir das Geparse sparen. Stattdessen könnte der Gui-Code direkt Funktionen des Tools aufrufen anstatt Kommandos in eine Pipe/Socket zu schreiben. Vorschläge? Meinungen? Erfahrungen? Danke fürs Lesen & schönen Freitag!