Kommander/GUI

Aus Linupedia.org
Version vom 4. November 2008, 20:58 Uhr von Escho (Diskussion | Beiträge) (Debug-Log fertig)
Wechseln zu: Navigation, Suche
Höhe=24px
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_fenster1
  • 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

Funktionsweise

Das Debug-Log funktioniert ähnlich wie das normale Log, wobei ich gestehen muß, ein paar kleine Feinheiten eingebaut zu haben. Aber die schauen wir uns später an, zuerst der Überblick:

Im DVB-Script wird der Standard-Fehlerkanal (stderr) in eine Datei geschrieben:

exec 2> ~/.dvb_script_gui.ini/debugfenster

Die Datei, die alle 500ms abgefragt wird, heißt diesmal debugfenster.

Wer nun denkt, hier erscheinen nur Fehlermeldungen, der sieht sich getäuscht. Bash-Anweisungen bzw. -Tools schicken auch Betriebsmeldungen über stderr. Wie gesprächig so eine Anweisung sein darf, das läßt sich oftmals einstellen über die Option --verbose.

Über den Clear-Button läßt sich der Text im Debug-Log löschen (Nur die Anzeige, nicht der Dateiinhalt, der wird erst beim nächsten Scriptstart niedergemacht).

Die Ein-/Aus-Knöpfe dienen zum Ein- bzw. Ausschalten der Anzeige im Debug-Log (vor dem Script-Start). Nach Beendigung des Script-Laufes kann mit ihnen der Scroll-Modus des Log-Fensters eingeschalten werden. Dann kann das komplette Log betrachtet werden.

Und noch eine letzte Kleinigkeit

Als Anzeigeobjekt habe ich diesmal nicht einen TextBrowser verwendet, sondern ein TextEdit-Feld, welches ich auf ReadOnly geschalten habe.

bekannte Bausteine 1

TextEdit

  • name: TextEdit_Debug_Log
  • minimumSize: Breite 470, Höhe 350
  • readOnly: Wahr

GroupBox

  • name: GroupBox2
  • title: LogDebug
  • hAlign: AlignHCenter
  • vAlign: AlignVCenter

ScriptObject

  • name: refresh_fesnster2
  • text: fen2

Kommandertext:

input=(env("HOME")+"/.dvb_script_gui.ini/debugfenster")
text=file_read(input)
TextEdit_Debug_Log.setText(text)
TextEdit_Debug_Log.scrollToBottom

Hier ist eine neue Funktion hinzugekommen:

TextEdit_Debug_Log.scrollToBottom

Diese Funktion sorgt dafür, daß in unserem Debug-Log immer das Ende der Log-Datei angezeigt wird.

Der Timer

  • name: Timer_Debug
  • interval: 500

Kommandertext:

refresh_fenster2.execute

Verbindungen (Signals und Slots)

Signale: GUI widgetOpened()

Slots: Timer_Debug execute()


Zwischenbemerkung 3

Bis jetzt war alles so, wie bein normalen Log-Fenster. Genauere Erklärungen erübrigen sich also. Kommen wir also nun zu den zusätzlichen Elementen:

Neue Bausteine

RadioButton

Ein-Knopf

  • name: RadioButton_Ein
  • text: Ein
  • checked: Wahr

Dieser Druckknopf hat zwei Zustände: gedrückt und nicht gedrückt. In diesem Fall wurde mit der Eigenschaft checked festgelegt, daß der Knopf per default gedrückt ist.

Für die beiden Zustände kann auch unterschiedlicher Kommandertext eingegeben werden. Das bedeutet, wenn der Button gedrückt ist, wird etwas anderes ausgeführt als in ungdrücktem Zustand.

Dies aber nur zur Information. Wir benötigen in unserem Fall gar keinen Kommandertext, da wir den Knopf über die signals and slots abfragen werden.

Aus-Knopf

  • name: RadioButton_Aus
  • text: Aus

Der Aus-Knopf ist per default nicht gedrückt.

ButtonGroup

Die beiden RadioButtons dürfen nur selektiv angesprochen werden können. Wenn also der eine Knopf An ist, muß der andere Aus sein. Das können wir erreichen, indem wir die Buttons in eine ButtonGroup packen.

  • name: ButtonGroup2
  • minimumSize: Breite 60, Höhe 60
  • exclusive: Wahr

Die ButtonGroup kann also über die Bezeichnung ButtonGroup2 angesprochen werden, hat eine Mindestgröße von 60 x 60 Pixeln und stellt sicher, daß exclusiv nur einer der enthaltenen Buttons gedrückt ist.

Layout

Das Layout ist schnell erledigt. Einfach die beiden RadioButtons in die Button Group schieben, diese markieren und auswählen: Bedienelemente im Raster anordnen


bekannte Bausteine 2

ExecButton

  • name: ExecButton_Clear
  • minimumSize: Breite 60, Höhe 60
  • text: Clear

Kommandertext:

RadioButton_Aus.setChecked(true)
Timer_Debug.cancel
TextEdit_Debug_Log.clear

Das Drücken des Clear-Buttons bewirkt also folgendes:

  • Der Aus-Knopf wird gedrückt (wodurch der Ein-Knopf wird über die Eigenschaft exclusive der ButtonGroup ausgeschalten).
  • Der Timer, der das Debug-Fenster mit Hilfe des ScriptObjects refresh_fenster2 ständig aktualisiert, wird gestoppt.
  • Und das Debug-Log-Fenster wird geleert.

Verbindungen (Signals and slots)

für den Aus-Knopf

  • Signale: RadioButton_Aus pressed()
  • Slots: Timer_Debug cancel()

Sobald der Aus-Knopf gedrückt wird, wird der Debug-Timer gestoppt.


für den Ein-Knopf

  • Signale: RadioButton_Ein pressed()
  • Slots: Timer_Debug execute()

Mit dem Drücken des Ein-Knopfes wird der Debug-Timer gestartet.

Diese Knöpfe lassen sich nicht mehr verändern, wenn eine Videobearbeitungsfunktion gestartet wurde. Sie müssen entweder vorher oder nach Abschluß der Bearbeitung eingestellt werden.

  • vorher: Die Anzeige des Debug-Logs kann aktiviert oder deaktiviert werden
  • nachher: Die Fokussierung der Anzeige auf das Dateiende kann ein- bzw. ausgeschalten werden.

Layout des Debug-Logs

So, die Programmierung des Debug-Logs ist nun abgeschlossen. Jetzt müssen nur noch die einzelnen Elemente dahin verfrachtet werden, wo sie in der fertigen GUI zu erscheinen haben.

Dazu machen wir die GroupBox so groß, daß alle eben erstellten Widgets hineinpassen. Und diese schieben nun wir in die Box (den Clear-Button, die ButtonGroup mit den Radio-Buttons und das Anzeigefenster TextEdit)

Zwischen die ButtonGroup und den Clear-Button fügen wir nun noch einen Abstand ein (Füge Abstand ein, so heißt das dazu notwendige Teil oben aus der Symbolleiste)

Nun markieren wir die GroupBox und ordnen die enthaltenen Bedienelemente im Raster aus (kennen wir schon, den Befehl, oder?) und stellen fest, daß wir fertig sind mit dem Debug-Log.

Übrigens, probiert es einmal aus und laßt den Abstand weg. Das gibt interessante Effekte beim Layout!


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