Eigenentwicklung: Grafische Oberfläche für das Terminal

[winix]

Hey Leute,
was haltet ihr von einer Desktop-Umgebung, die im Linux-Terminal läuft? Ihr wisst schon, sowas wie KDE oder Gnome oder Windows, nur eben im Terminal. Ich finde eine Umgebung mit Taskleiste, Startbutton und Fenstern auf die Dauer viel besser als dauernd lange Befehlsketten einzugeben. Man kann das System ja dann um die Anwendungen erweitern, die man regelmäßig braucht und könnte dann alles mit der Maus bedienen.
Ich habe bereits einer erste Version entwickelt und bin der Meinung, dass so etwas die Vorteile des Terminals mit den Vorteilen einer Benutzeroberfläche vereint. Sowas müsste doch vorallem von Unternehmen nachgefragt werden, da die einmalige Implementierung von Prozessen und anschließende Durchführung per one-click deutlich Zeit und Kosten im Alltag spart, als eben entsprechende Befehle tagtäglich in das Terminal einzugeben. Außerdem könnten komplizierte Prozesse, die vorher nur über das Terminal durchgeführt werden konnten auch von ungeschultem Personal erledigt werden.
Verzeiht, falls das hier das falsche Unterforum ist...
Ich habe mal einen Screenshot meiner Entwicklung angehängt.

Ich freue mich über konstruktives Feedback!

Schöne Grüße

 

[towo]

http://www.linuxforen.de/forums/showthread.php?t=277028

 

[TomcatMJ]

Wirkt für mich wie ein Windowmanager ohne X-Abhängigkeit. Für Leute die ernsthaft an ausgewachsenen PCs auf Konsolenebene arbeiten wollen wohl eher ne Art Platzverschwendung ohne produktiven Nutzen, aber für Embedded-Systeme ohne nennenswerte Grafikleistung durchaus verwendbar wenns denn mit Touchscreensupport auch für Miniaturtouchscreens daherkommt. Für kleinere Systeme wie Messgeräte mit älteren ARM-Prozessoren, älteren MIPS-Prozessoren oder etwas kräftigeren Microcontrollern sicherlich verwendbar, aber für alles was bischen mehr Grafikpower mitbringt wohl doch wieder zu spartanisch, Navi-Systemanzeigen oder Mini-Videoanzeigeoptionen dürften da wohl eher nicht laufen da es Textmodebasiert ist aber für z.B. die Steuerung eines Hausautomationssystems, einer Lichtanlage, einer Mikrowelle oder einer Waschmaschine könnte es nützlich sein

 

[abgdf]

Hmm, ja, ok, aber ist das nicht das, was ncurses macht?

http://de.wikipedia.org/wiki/Ncurses

Mit Mouse-Support (wenn man ihn denn haben will) über GPM?

http://en.wikipedia.org/wiki/GPM_(software)

Ich meine, z.B. den Midnight Commander (mit einer Art von Grafik in der Konsole) setze ich ja den ganzen Tag ein ...

 

[winix]

Vielen Dank für eure Beiträge, insbesondere auch an TomcatMJ. Du bist der zweite, der die Idee mit den embedded-Linux-Systemen noch einmal bestätigt. Das macht mir natürlich Mut.

GPM ist ebenfalls ein guter Vorschlag für den Einsatz außerhalb des X Window Systems. ncurses wird von der Software nicht benötigt, die graphischen Funktionen habe ich selbst implementiert.

Gibt es z. B. für Webhoster jedoch nicht auch gewisse Vorteile, wenn ähnliche Aufgaben wiederholt erledigt werden müssen, z. B. die Bereinigung von Verzeichnissen um bestimmte Dateien? Wäre hier ein "Windows"-Formular mit Checkboxes nicht einfacher, als teils sehr komplizierte Befehlsketten?

Ich freue mich auf euer weiteres Feedback.

 

[Rainer Juhser]

Gibt es z. B. für Webhoster jedoch nicht auch gewisse Vorteile, wenn ähnliche Aufgaben wiederholt erledigt werden müssen, z. B. die Bereinigung von Verzeichnissen um bestimmte Dateien? Wäre hier ein "Windows"-Formular mit Checkboxes nicht einfacher, als teils sehr komplizierte Befehlsketten?

Dafür schreibt man sich ein Shell-Skript, das man dann auch bei regelmäßiger Wiederholung über die crontab auch automatisch ausführen lassen kann.

 

[abgdf]

ncurses wird von der Software nicht benötigt, die graphischen Funktionen habe ich selbst implementiert.

Die Software wird nicht benötigt, weil ihre graphischen Funktionen bereits in ncurses implementiert sind.

So herum wird ein Schuh draus.
Andererseits kann es auch nicht schaden, das Rad nochmal neu zu erfinden. Tu' Dir keinen Zwang an.
Manchmal ist man mit einer bestehenden Lösung auch nicht zufrieden und schreibt deshalb nochmal was Neues. Schon möglich.

 

[TomcatMJ]

Naja, ich würde den Vorteil darin sehen daß da eventuell diverse Messwerterfassungssoftware die sonst nur eine reine Textausgabe produzieren würde in mehreren Instanzen nebeneinander laufen könnte, was bei ncurses etwas schwieriger ist, da ncurses einzeln pro Programm eingebunden werden müsste oder man ein spezielles Programm genau dafür bauen müsste was die Erfassungssoftware einfasst und dann feststeht.
Dialog wäre ja in Shellscripten ein Weg etwas an den Eingaben optisch aufzuwerten, aber für die Ausgaben in einem Shellscript gibts kaum was was das aufhübschen kann.
Ich finde das angesprochene Framework (ich nenns jetzt einfach mal so weil es ja offenbar keine Biblithek zum einbinden darstellt sondern eher einen Rahmen für due Ein+Ausgaben vorhandene Software zu stellen scheint) wie ein Window-Manager nur ohne X und auf der Konsole laufend.

Einsatzzwecke sähe ich dann halt wie gesagt als Statusanzeigen und Eingabesteuerung im Bereich der Hausautomation, Statusanzeigen für z.B. CNC-Werkzeuge am Gerät selbst statt nur am eigentlichen Steuerungsrechner, bei KFZ-Werkstätten mit Messwerterfassung per z.B,. Rasperry PI basierten Messstationen anstelle eines fetten normalen Rechners, der für die anzuzeigenden Messwerte meist doch Overkill wäre und platzfressender wäre, für Ein- und Ausgaben von Wetterstationen (Eingabe z.B. der Messintervalle und der zu loggenden Sensordaten, Ausgabe der Daten auf dem Display, Menüführung für die Auswahl der Anzeige und der Messaufgaben etc.)...eng würde es wohl im Bereich der grafischen Verlaufsdarstellung werden, für z.B. Temperaturkurven, Leistungskurven+Zündungzeitpunktskennlinien (im KFZ-Bereich) etc., aber für Bargraph-Anzeigen wäre es sicherlich auch geeignet.
Wenn es mit HD 4770 Displays auch funktioniert wäre es wohl auch durchaus für Statusanzeigen an DMX/RDS basierten Lichtanlagensteuerungsgeräten verwendbar die oft "nur" mit Microcontrollern statt ausgewachsenen Prozessoren arbeiten und wo es durchaus auch Systeme auf µc-Linux Basis existieren und wo ncurses meist dann doch zu platzfressend ist.

Wenn es also kompakter als ncurses ist, womöglich inklusive Touchscreensupport, könnte es da wirklich eine Alternative darstellen, auch wenn es bis dahin sicherlich ein verdammt langer Weg werden dürfte.
Ob das Ganze nun die Windows 286 Optik aus dem Screenshot behält oder nicht ist dabei ja erstmal egal, denn Optik ist einfach Geschmacksfrage und sollte letztendlich flexibel anpassbar sein geht ja mehr um das was dahintersteckt als ums "Kleid"..

 

[winix]

Hallo,

vielen Dank nochmal an TomcatMJ für die abermals sehr ausführliche und ausgewogene Antwort.

In Folge stellt sich mir die Frage nach dem Touchscreen-Support in der einfachen Linux-Kommandozeile (Bash, außerhalb von X-Window; in xterm funktioniert schon alles). Hier eine Software für alle möglichen Hardwarekonstellationen selbst zu schreiben, scheint aus ökonomischer Sicht kaum vertretbar. Nach Recherchen habe ich gesehen, dass einige Raspberry-Nutzer dies mit Mühe für ihre spezifische Hardware (für X-Window(-ähnliche) Umgebungen) realisiert haben.

Doch dieses Thema macht den Eindrück, als könnte es eine ziemliche Herausforderung werden. Hat jemand irgendwelche Erfahrungen damit oder Kenntnisse davon, ob es bereits Software gibt, die ohne Programmierung irgendwie dafür eingesetzt werden kann, eine Touchscreen-Unterstützung für die reine Linux-Bash umzusetzen (richtig kalibriert, mit korrekten Koordinaten)?

Ich bin für jeden Hinweis dankbar.

http://forum.linux-club.de/viewtopic.php?f=90&t=119427

Viele Grüße