Kommander/GUI

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

Einführung: Der Weg zur GUI - Die Funktionen - Screenshots

Das Editorfenster

So sieht die GUI aus wenn sie zum Editieren mit dem kmdr-editor aufgerufen wird: Editor-Dialog

Gliederung der GUI

Ich habe die GUI in vier große Abschnitte eingeteilt:

Aktionenauswahl

Links oben können die gewünschten Aktionen durch Drücken vom Buttons ausgewählt werden. Folgende Kommander-Widgets sind dabei beteiligt:

• RadioButton: Auswahl der Aktionen (Brennen, Sichern, usw.)
• Label: Dient zur Anzeige von Kommentaren (Video-DVD...)
• ButtonGroup: Hierin sind die RadioButtons und die Labels organisiert
• ExecButton: Damit wird die ausgewählte Aktion gestartet (Go)
• EditorTabWidget: Weitere Aktionen können über Reiter sichtbar gemacht werden

Log

Im Log-Fenster links unten wird der Bearbeitungsfortschritt der gestarteten Aktion angezeigt. Hier bürgen folgende Widgets für das Gelingen:

• TextBrowser: Hierin erfolgt die Anzeige
• GroupBox: Sieht einfach besser aus, wenn der TextBrowser da drin liegt

Debug-Log

Rechts unten ist das Debug-Log zu finden. Damit kann man, wenn es gewünscht wird, noch genauere Anzeigen des laufenden Scripts bekommen. Da hier die Ausgabe des Standard-Fehlerkanal angezeigt wird, kann man gut nachverfolgen, wo es Probleme gegeben hat, wenn etwas nicht so klappt, wie man es sich eigentlich vorstellt.

• TextWidget: Ausgabe von stderr (Standard-Fehlerkanal)
• RadioButton: Steuern die Aktualisierung der Ausgabe (Ein, Aus)
• ButtonGrop: Darin sind die RadioButtons organisiert
• ExecButton: Fensteranzeige leeren (Clear)
• GroupBox: Läßt das, was zusammen gehört, auch so erscheinen

Unsichtbare Widgets

Klingt gut, der Titel, oder? Ja, die Widgets rechts oben sind tatsächlich unsichtbar im kmdr-executor. Editiert man aber den Dialog, sieht man sie (kmdr-editor).

• ScriptObject: Diese drei Objekte enthalten ausführbaren Kommander- bzw.Bash -Code
• Timer: Periodische Abfrage der Anzeigefenster bzw. Zeitverzögerung
• blaue Abstandslinien: Sind für das Layout wichtig

Das Formular

Wir haben bereits in der Einleitung gesehen, wie ein neuer Kommander-Dialog erstellt wird. Ganz kurz noch einmal zu Wiederholung:

• kmdr-editor starten
• Dialog drücken bzw. Datei - neu
• Den Dialog speichern unter einem sinnvollen Namen

Das Formular (EditorDialog) bekommt von uns nun folgende Eigenschaften zugeteilt:

• name: GUI
• baseSize: Breite 1024, Höhe 768
• caption: dvb_wiki_script oder Vom DVB zur DVD und einiges mehr

Die Zuteilung eines aussagekräftigen Namens, mit dem das Element angesprochen werden kann, ist eminent wichtig. Ich hatte dies beim Programmieren der GUI versäumt. Erst, als die Zuordnung der Elemente mit steigender Komplexität des Dialogs immer undurchsichtiger wurde, habe ich nachträglich Namen vergeben.

Die Basis-Grösse ist die Fenstergrösse, mit der Kommander den Dialog startet. Man könnte auch sagen, der Dialog ist optimiert für eine Bildschirmgrösse von 1024 x 768 Pixel.

Und die Überschrift... Na ja, irgend etwas musste ich ja rein schreiben.

Das Log

Weiter mit dem Log-Fenster links unten.

Funktionsweise

Das DVB-Script ist so programmiert, daß immer wieder Meldungen über den aktuellen Fortschritt der Videobearbeitung in eine Datei geschrieben werden:

text >> ~/.dvb_script_gui.ini/fortschrittfenster

Wie zu sehen ist, werden diese Texte zum schon vorhandenen Dateiinhalt hinzugefügt.

Diese Fortschrittsdatei wird von Kommander mit Hilfe eines Timers und eines ScriptObjects alle 500ms abgefragt. Das Ergebnis der Abfrage wird dann in das Log-Fenster (den TextBrowser) geschrieben.

Bausteine

TextBrowser

Wir plazieren einen TextBrowser (aus der Symbolleiste) irgendwo auf dem Formular und stellen folgende Eigenschaften ein:

• name: fenster1
• minimumSize: Breite 490, Höhe 350

Die Angabe einer Minimum-Größe ist notwendig, damit das Fenster beim Layout nicht geschrumpft wird.

GroupBox

Auch dieses Widget wird auf eine freie Stelle im Formular kopiert.

• name: rahmen
• font-Punktgröße: 12
• font-Fett: wahr
• title: Log
• hAlign: AlignHCenter
• vAlign: AlignVCenter

Was ist hier besonderes?

Der Fenstertitel Log wird vertikal und horizontal zentriert (Align) dargestellt, erhält zur Hervorhebung eine Schriftgröße von 12 Punkten und wird zusätzlich fett formatiert.

Layout

• Mit der Maus wird die GroupBox so groß gemacht, daß der TextBrowser vollständig hineinpasst
• Anschließend wird der Browser in die Box geschoben
• Die Groupbox wird markiert und aus dem Kontextmenue folgender Befehl ausgewählt:
• In einem Raster anordnen (Die neun kleinen Quadrate)

Damit ist der TextBrowser fest in der GroupBox verankert und kann zusammen mit der Box an einen passenden Ort auf dem Formular geschoben werden.

Das Log-Fenster ist fertig. Es fehlt nur noch der Inhalt.

ScriptObject

Wir haben vorhin gesehen, daß der Bearbeitungsfortschritt des DVB-Scriptes in folgende Datei geschrieben wird:

~/.dvb_script_gui.ini/fortschrittfenster

Den Inhalt dieser Datei fragen wir mit einem ScriptObject ab.

Erzeugen wir also ein ScriptObject mit folgenden Eigenschaften:

• name: refresh_fesnster1
• text: fen1

Unser ScriptObject enthält, wie der Name schon andeutet, ausführbaren Scriptcode. In welcher Sprache wir das Script erstellen, bleibt uns überlassen. Verwenden wir diesmal den Kommander-Scriptcode:

input=(env("HOME")+"/.dvb_script_gui.ini/fortschrittfenster")
text=file_read(input)
fenster1.setText(text)

Um diesen Code einzugeben, haben wir aus dem Kontextmenue des ScriptObjects natürlich den Punkt Kommander-Text bearbeiten ausgewählt.

Hier kommt nun eine kurze Erläuterung zu diesem Dreizeiler:

Die Shell-Variable HOME enthält den Pfad zum Heimatverzeichnis. In der ersten Zeile des Scriptes wird der Inhalt dieser Shell-Variablen mit dem String /.dvb_script_gui.ini/fortschrittfenster addiert. Das Ergebnis dieser String-Addition ist die vollständige Pfadangabe zm fortschrittfenster. Dieser Pfad wird in die Variable input geschrieben.

In der zweiten Zeile wird der Inhalt der Datei ~ /.dvb_script_gui.ini/fortschrittfenster gelesen und in die Variable text geschrieben.

Und in der dritten Zeile wird der Dateiinhalt als Text an das Widget fenster1 übergeben.

Zwischenbemerkung 1

Habe ich übrigens schon erwähnt, daß es nicht ganz ohne Sinn ist, die bisherige Arbeit von Zeit zu Zeit zu speichern? Falls nicht, dann erinnere ich hiermit daran. Falls doch, na ja, dann schadet es auch nichts, noch einmal davon zu sprechen.

Zwischenbemerkung 2

Wir haben bis jetzt folgende Widgets installiert:

• Formular mit dem Namen GUI
• GroupBox mit dem Namen rahmen
• TextBrowser mit dem Namen fenster1
• ScriptObject mit dem Namen refresh_fenster1

Widgets lassen sich im Programm über ihre Namen ansprechen. Wir können die Eigenschaft text des TextBrowsers also auch per Programm füllen, was wir mit dem Dreizeiler ja tun. Dieser Text erscheint dann im Ausgabefenster des TextBrowsers, also in unserem Log-Fenster.

Was uns nun noch fehlt, das ist, den Dreizeiler zu starten, und zwar regelmäßig. Doch auch hierfür bietet Kommander ein Widget an, nämlich den Timer, der in der Symbolleiste aussieht wie ein uralter Wecker.

Also, installieren wir im Formular einen solchen Timer und geben ihm folgende Eigenschaften:

Der Timer

• name: Timer_Log
• interval: 500

Das bedeutet, alle 500ms wird das getan, was wir in den Kommander-Text des Timers geschrieben haben bzw. jetzt schreiben werden:

refresh_fenster1.execute

Diese Anweisung bewirkt, daß der im ScriptObject enthaltene Code alle halbe Sekunden ausgeführt wird.

Jede halbe Sekunde wird also der Inhalt der Datei ~ /.dvb_script_gui.ini/fortschrittfenster in die Eigenschaft text von fenster1 geschrieben und damit angezeigt.

Ganz fertig sind wir aber immer noch nicht, denn der Timer muß erst einmal gestartet werden:

Verbindungen (Signals und Slots)

Wie das mit den Verbindungen funktioniert, habe ich in der Einleitung zu erklären versucht. Hier die aktuelle Anwendung dieses Prinzips von signals and slots:

• Signale: GUI widgetOpened()
• Slots: Timer_Log execute()

Wenn das Formular mit dem Namen GUI geöffnet wird (was immer dann passiert, wenn wir den Dialog starten), dann läuft der Timer los.

Und damit ist, nebenbei gesagt, die Programmierung des Log-Fensters abgeschlossen. Weiter geht es mit dem DebugLog.

Das Debug-Log

Einführung: Der Weg zur GUI - Die Funktionen - Screenshots