For about one year, the paper tape project has stopped from emerging the planned "Paper Tape Suite". Nowadays, there's a big crowd of files (many copies) lying around and waiting for being ordered, corrected, extended.
These are some plans for the near future:
The following text gives some overview about the rewriting plans
The Paper Tape Project -- TODO and Goals, 22.09.08
==================================================
Folgende Aufgaben, im Groben, stehen noch an:
* Saubere Treiber(-Schnittstelle) für den Leser
* The Paper Tape Suite
Nun im Einzelnen:
Was zusammengehört, wächst letztlich zusammen: Während bereits
die Puncher-Treiber umgezogen sind von /userspace-driver zu
/driver und dabei ein sauberes Backend/Frontend-System gekriegt
haben, soll selbiges jetzt auch den Leser-Treibern widerfahren.
Dabei ziehen alle Treiber-Backends, nach Betriebssystemen geordnet, in
das /driver-Verzeichnis um. Wie das dann letztlich aussieht, weiß
ich noch nicht genau.
The Paper Tape Suite: Das erklärte Endziel dieses Projektes ist
ein umfassendes "All in one" GTK-Programm, welches folgende
Generalfeatures vereint:
* Lochstreifendateien öffnen und anschauen, mit allen bereits
bekannten Flexibilitäten von GtkPaperTape
* Lochstreifen auch bearbeiten: Einen vollen Binäreditor in
allen Regeln der GTK+-Kunst, d.h. native Benutzung: Kopieren,
Verschieben, Auswählen, etc.
* Lochstreifenschriften, Beschriftungen an beliebigen Stellen
einfügen
* Ausstanzen der aktuellen Lochstreifendatei auf beliebige
Stanzer auf beliebigen Betriebssystemen (das Backend benutzend)
* Einlesen von Lochstreifendaten von beliebigen Lesern auf
beliebigen Betriebssystemen
Mit GtkPaperTape existierte bereits eine voll funktionsfähige
C-Implementierung eines Lochstreifenbetrachters. Wegen den
nun wesentlich gestiegenen Anforderungen wurde dieses System
in C++ von Grund auf neu programmiert. Dabei wurden viele Bugs
und Probleme beseitigt und längst überfällige Funktionen
implementiert. Auf der anderen Seite ist die Entwicklung recht
komplex, birgt viele neue Gelegenheiten für Bugs und geht wegen
ihres enormen Umfangs alles in allem auch sehr träge vorran.
Die gestiegenen Kompilierzeiten tun ihr Übriges dazu (alleine
Gtk::PaperTape mit allen Abhängigkeiten zu kompilieren dauert
auf meinem Pentium IV etwa eine halbe Minute).
Der Stand der Dinge:
Die Gtk::PaperTape-Implementierung hat im Grossen und Ganzen
jetzt den Funktionsumfang erreicht, den die C-Implementierung
"GtkPaperTape" auch bot. Dabei wurden bereits etliche neue
Funktionen (auch testweise) implementiert:
* Ein System mit einigen Objekten, welches vor allem in
Bezug auf Namensgebung allerdings nochmal etwas überarbeitet
werden muss.
* Action-basierte Menues, eine Toolbar
* Viele freundliche Einzeldetails, z.B.
* mächtiges Exportwerkzeug mit Auswahloptionen und
Fortschrittsbalken
* mächtigeres Zoomwerkzeug mit Direktzugriff auf die
affine Abbildungsmatrix
* mächtigeres Farbenwerkzeug mit Alpha-Unterstützung
und Ein/Ausschaltbaren Komponenten
* Erste Bearbeitungsfunktionen: Im momentanen Viewer können
Bits durch Klicken ein- und Ausgeschaltet werden. Dies
funktioniert exzellent ohne Bugs.
* Sehr ausgereiftes Zeichnungssystem, welches wirklich nur
die benötigten Komponenten zeichnet. Einige wenige
Bugs existieren noch, traurig ist der noch immer vorhandene
Scrollbug (Inhalt bleibt stehen), der aber *aller*
Wahrscheinlichkeit nach ein Gtk+/Xlib/Cairo-Problem ist.
Ich hab ihn im Gtk+-Bugtracker verzeichnet, siehe
http://bugzilla.gnome.org/show_bug.cgi?id=552672
Ich denke, dass die Neuerungen bereits Wegweisend sind. Dank
C++ ist das Widget zudem jetzt wesentlich leichter erweiterbar,
was die Implementierung von neuen Funktionen erleichtert.
TODO
====
Nun eine Liste der Dinge, die noch fehlen oder buggen:
Bugs/fehlende Funktionen:
* PaperTapeExporter: Stürzt ab oder zeigt Oberfläche nicht
richtig. Abbrechen-Button ist immer noch nicht anklickbar.
Problem hier vielleicht static- oder Heap-Elemente?
* PaperTapeZoom: Einbindung in LOCHSTREIFEN nicht gut,
LOCHSTREIFEN->matrix müsste wieder ein Pointer werden.
Es fehlen noch Flip-Funktionen, ausserdem sind die Rotate-
Funktionen nicht praktisch (nur 90°-Vielfache sollten
möglich sein). Auto-Resizing ist umständlich, weil es
bei der GtkScrolledArea die Scrollwidgets abschalten muss,
PaperTapeZoom braucht also vollen Zugriff auf die View
und den Controller. Deshalb: ScrolledArea in die View-
Kompetenzen rübernehmen! Controller zur Chrome umbenennen,
Controllerkompetenzen schwächen!
Neue Funktionen:
* PaperTapeFont: Einbindung des C-"PaperTapeFont"-Systems fehlt
* Auswählen geht noch nicht, außerdem Kopieren und Einfügen
* Problematik immer noch: Cursormetapher -- zwischen Bytes
gehen oder immer im "Overwrite"-Modus?
-- Sven @ 22.09.08 03:00, workstation