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.
Gast
#5873430
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/
Gast
#5873576
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.
Gast
#5874088
dann wäre da noch zenity https://de.wikipedia.org/wiki/Zenity
NichtWichtig schrieb: > zenity Gut zu wissen, danke.
Gast
#5874545
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.
Gast
#5874647
PythonQt o. Qt C++, dass IPC zu deinem Scripten dürfte nicht schwer sein.
Gast
#5875668
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?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.