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