Seit Mai 2011 gibt es Aktivitäten, die bisherige GUI neu zu implementieren. Das hat hauptsächlich mit der (Anzeige-)Größe der bisherigen GUI zu tun, wurde dann aber zu einem Anlaß, die komplette GUI neu zu entwickeln.

Daraus entwickelte sich dann der konsistente Ansatz, alle Funktionen in erster Linie über die GUI zugänglich zu machen, auch wenn sie nach wie vor über die Kommandozeile zugänglich sind.

Die bisherige GUI ist zu groß, als daß sie auf meinem MacBook Pro (1280×800 px Bildschirmauflösung) funktionierte. Das gab den Anstoß dazu, die bestehende GUI umzugestalten. Technisch lief es auf eine Reimplementierung weiter Teile der Toolbox heraus.

Gleichzeitig kam verstärkt die der Wunsch auf, auch andere als die bisherigen Daten (trEPR-Daten aus Berlin und Freiburg) in der GUI anzeigen zu können, sowie weitere Funktionen einzubauen.

Der momentane Ansatz ist, eine möglichst modulare GUI zu entwickeln, deren Datenschema und anderweitige Programmierung den Umständen entsprechend transparent, durchschaubar und einfach erweiterbar bzw. an andere Anforderungen anpaßbar ist.

Es folgt eine Serie von Screenshots mit jeweiliger Beschreibung der geplanten Funktionen. Diese Darstellung dient gleichzeitig der Dokumentation der zugrundeliegenden Ideen bei den einzelnen Elementen.

• Hauptfenster

Weitere Fenster

• Akkumulieren
• Baseline Correction
• Line style
• Info
• …

• programmatisch, nicht mehr über GUIDE
• einzelne zusammengehörige Teile der GUI in einzelnen Funktionen
  • Diese GUI-Unterfunktionen sind im Verzeichnis „private“ gespeichert, so daß die Haupt-GUI-m-Datei darauf zugreifen kann, sie ansonsten aber nicht erscheinen und für Konfusion sorgen.
• Pseudo-Tabs: einzelne übereinanderliegende Panels, zwischen denen durch darüber angeordnete Schaltflächen umgeschaltet werden kann
  • jedes dieser Panels faßt logisch zusammengehörende Anzeigen und/oder Funktionen zusammen

• Transparenz in der Programmierung
• stabiles Laden und Anzeigen einer Vielzahl unterschiedlicher Daten (1D und 2D)
• modularer Aufbau
  • Von Anfang an ist geplant, aufbauend auf demselben Konzept mit den gleichen Modulen (mit geringen Änderungen) eine Toolbox für TA-Daten zu bauen.
• Historie der Manipulationen von Daten
  • Diese Historie sollte möglichst nicht nur anzeigbar sein, sondern auch noch zusammen mit den jeweiligen Datensätzen gespeichert werden.
  • Idealzustand: Historie kann geladen werden und ermöglicht damit die Wiederholung der Prozesse bzw. die Anwendung auf andere Datensätze.
• strikte Trennung zwischen GUI und eigentlicher Datenmanipulation
  • Nur GUI-interne Dinge (Interaktion der verschiedenen Elemente) werden innerhalb der GUI-Funktionen abgelegt.

• Historie
  • für jeden Datensatz
  • pro Schritt komplette Information, was gemacht wurde
    • Funktionsname
    • Parameter, soweit notwendig
    • Rückgabeparameter, soweit notwendig
  • Historie wird grundsätzlich mit den Datensätzen mitgespeichert
    • macht es, im Zusammenhang mit der Undo-Funktion (s.u.) evtl. notwendig, zwischen der Historie der aktuellen und der vorheriger Sitzungen zu unterscheiden
    • Wenn man die Historie eines Datensatzes mit dem Laden mitläd, könnte man diese evtl. an einer anderen Stelle in der appdata-Struktur speichern als die Historie der gegenwärtigen Sitzung: Geladene Historie zu den anderen Daten des geladenen Datensatzes, aktuelle Sitzungshistorie in einem entsprechenden History-Feld der appdata.
• Undo-Funktion
  • macht eine Ablage der ursprünglich geladenen Daten notwendig
  • ermöglicht zusammen mit der Historie eine weitgehende Rückkehr zum „originalen“¹⁾ Datensatz
• Laden nahezu beliebiger 1D- und 2D-Datensätze
• Auslagern von GUI-Funktionalitäten wie das Aktualisieren der Achsen in eine eigene Funktion, die dann von allen Callback-Routinen der unterschiedlichen GUI-Teile aufgerufen werden kann
  • durch die Verwendung des „private“-Verzeichnisses innerhalb des Verzeichnisses „GUI“ problemlos möglich
• Statusfenster
  • Anzeige aktueller Statusmeldungen, inkl. Erfolg und Mißerfolg durchgeführter Aktionen
  • ersetzt nicht die Historie eines Datensatzes, die mit dem jeweiligen Datensatz verknüpft ist