Hallo zusammen. Ich schreibe eine Reihe von tools, bei denen ich das erste Mal damit konfrontiert bin, dass ich Rücksicht auf den Anwender nehmen muss und der nicht nur ich sein werde. Ich könnte Hilfe bei der Entscheidung brauchen, wie ich das UI gestalte. Die tools sind grundsätzlich erstmal Bash Skripte, die auf eine REST API zugreifen, die XML versteht. Die Skripte sollten auch weiterhin wie gewohnt nutzbar sein. Zusätzlich müssen aber auch Leute, die von Linux 0 Plan haben, in der Lage sein, sie zu benutzen. Wie bekomme ich grundsätzlich auf solche Skripte einen intuitiv zu benutzenden "head" drauf? Welche Technologien sind empfehlenswert und was sind dann jeweils die Anforderungen an die Skripte? Ich hatte bisher folgende Ideen: 1. Browser basiert: Grundsätzlich natürlich aus den bekannten Gründen attraktiv. Die Leute können sich eh per Remote Desktop an einem XFCE Desktop anmelden. Ich möchte aber dafür nicht extra einen Webserver betreiben. Kann man das irgendwie als lokale Dateien machen? Gerate ich da möglicherweise in irgendwelche Same-Origin-Policy-Probleme oder sowas? Dieses Webgedöns ist leider nicht so meins. 2. Kommandozeile interaktiv: Quasi guided, falls das Skript mit ohne Paramter aufgerufen wurde. Mit viel Einsatz von read und co. Wär für mich grundsätzlich ok. Aber wie findet das ein Nicht-Linuxer? Insbesondere, wenn das ganze etwas länger wird. 3. ncurses oder Ähnliches Kenn ich mich nicht mit aus. Lohnt es sich, sich das mal anzuschauen? Ich hab da den Verdacht, dass das in der Nutzung etwa so effizient wie Option 2 ist, bloß mit mehr Arbeit beim erstellen. 4. Die Skripte verwerfen und was komplett neues nehmen: Am besten fände ich eine Art XML-Explorer, der die REST API ansprechen kann und den ich dahingehend programmieren kann, dass er Aktionen auf die Elemente ausführen kann. Gibt es sowas vielleicht schon? Kann man sich sowas mit überschaubarem Aufwand selber bauen? Emacs? Vim? Qt? Irgendwas? Danke fürs Lesen
Divide et impera. Schreibe ein neues Tool und lasse es als GUI laufen, was einfach im Hintergrund die vorhandenen Skript(e) mit passenden Parametern aufruft. Ist je nach Wissensstand mit perl/Tk oder TCL/Tk gar nicht sooo kompliziert. Wenn der $LUser das vorhandene Skript aufruft, kann man den Namen des GUI Tools ja mit im "Usage" ausspucken.
Ich werfe mal Python/Tk in den Raum. Reicht für einfache UIs und du hast halt das ganze Drumherum. https://de.wikipedia.org/wiki/Tkinter https://docs.python-guide.org/scenarios/xml/ https://realpython.com/api-integration-in-python/
Schau dir mal "dialog" an - ist speziell dafür gedacht, shell-Skripten ne (Text-basierende) GUI zu spendieren.
Jim M. schrieb: > Schreibe ein neues Tool und lasse es als GUI laufen, was einfach im > Hintergrund die vorhandenen Skript(e) mit passenden Parametern aufruft. > > Ist je nach Wissensstand mit perl/Tk oder TCL/Tk gar nicht sooo > kompliziert. Klingt grundsätzlich vernünftig, weil die Skripte dann keinerlei Anpassung brauchen. Wird wohl der Fallback werden, falls komplexere Sachen zu komplex werden. ichversuchsmal schrieb: > Ich werfe mal Python/Tk in den Raum Jepp, wenn Tk, dann werde ich es wohl mit Python angehen. foobar schrieb: > Schau dir mal "dialog" an Ja, kenn ich, finde ich auch gut. Fand ich aber aus dem Bauch heraus für das konkrete Vorhaben ähnlich wie ncurses und read nicht ganz optimal. Eine ganz andere Idee, der ich jetzt auch nachgehe ist, den XML Editor treeline um API Funktionalität zu erweitern. Ich bin zwar kein Python Profi, aber das bekomme ich glaube ich hin. Ich wäge Aufwand und Nutzen mal ab. Das ist zwar mehr, als ich vorhatte, aber auch die reinen Skripte müsste ich ansonsten erweitern, weil die stark auf Verwendung mit grep, sed und co. ausgelegt sind. Danke erstmal für die Vorschläge, das sind die Stichworte, die ich brauchte.
Nimm die Technologie, mit der du am schnellsten einen Prototypen zusammen klopfen kannst. Ganz egal, welche Technologie du nimmst und welche Abstraktion die Oberfläche bietet - deine Benutzer wollen es anders haben. Der einzige Fehler, den du bei so etwas machen kannst: In die erste Version zu viel Arbeit stecken. Dann willst du den Prototypen nicht mehr wegwerfen und handelst dir Probleme ohne Ende ein.
PythonQt o. Qt C++, dass IPC zu deinem Scripten dürfte nicht schwer sein.
Md M. schrieb: > Irgendwas? Woher sollen wir wieder wissen was dir am besten gefällt? Das geht mit allem, selbst dein bash-Pfusch erfüllt den Zweck. Also such dir selber was aus was am besten passt.
Bettlerwabwehr 2.0 schrieb: > Woher sollen wir wieder wissen was dir am besten gefällt? Ganz einfach: Ich habe geschrieben, was ich am besten fände. Extra für dich betreutes Lesen: Md M. schrieb: > Am besten fände ich eine Art XML-Explorer, der die REST API ansprechen > kann und den ich dahingehend programmieren kann, dass er Aktionen auf > die Elemente ausführen kann. Gibt es sowas vielleicht schon? Kann man > sich sowas mit überschaubarem Aufwand selber bauen? Emacs? Vim? Qt? > Irgendwas? Bettlerwabwehr 2.0 schrieb: > Das geht mit > allem, selbst dein bash-Pfusch erfüllt den Zweck. Woher weißt du das? Und woher weißt du, dass sie Pfusch sind? Kennst du die Skripte? Sie erfüllen ihren Zweck eben nicht mehr. Nochmal betreutes Lesen für dich: Md M. schrieb: > Die Skripte sollten auch weiterhin wie > gewohnt nutzbar sein. Zusätzlich müssen aber auch Leute, die von Linux 0 > Plan haben, in der Lage sein, sie zu benutzen. Bettlerwabwehr 2.0 schrieb: > Also such dir selber > was aus was am besten passt. Versteht sich irgendwie von selbst, oder?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.