home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-385-Vol-1of3.iso
/
g
/
gina15.zip
/
TODO
< prev
Wrap
Text File
|
1992-02-27
|
5KB
|
148 lines
Internes Dokument ! @(#)TODO 1.6 2/26/92
Diese Datei enth"alt Gedanken zu Erweiterungen und Verbesserungen zu C++ GINA.
Idee: Jeder schreibt seine Ideen auf, jeder kann Anmerkungen hinzuf"uegen.
->> neuere Sachen nach vorne !!!
AB 20.2.92
==========
- Die Funktion GnApplication::app_class() sollte entfernt werden, da ihre
Funktionalitaet vom Meta-Object-Protokol uebernommen werden kann; Man
muss dann GnApplication::Class()->Name() benutzen.
- Die Funktion GnApplication::create_document() sollte in CreateEmptyDocument()
umbenannt werden, um zu verdeutlichen, dass ein neues, leeres Dokument
erzeugt wird. (Im Zuge der Anpassung an Namenskonventionen.)
- Die Funktion GnDocument::create_view() kann weg, da ein View meist explizit
vom Programmierer erzeugt wird. Ausserdem entspricht sie nicht der
Philosophie, das es mehrere und verschiedenartige Views auf ein Dokument
geben kann.
- In allen Makefiles muss /usr/lang in /vol/lang umbenannt werden, da z.B.
auf jumbo_f3/f3svb kein C++ unter /usr/lang existiert.
AB 6.2.92
==============
Das Menusystem muss ueberarbeitet werden:
- Anpassung an Lisp-Gina funktionalitaet (Handbuch)
- Mnemonics, Accelerator
- Loeschen, Hierarchische Menues, Toggle-Eintraege
- Toggle/Radio-Groups in Menues
Andreas 31.1.92
===============
- ViewObjekte sollten nicht im View, sondern im Dokument abgelegt sein.
VORTEIL: Es kann gleichzeitig mehrere Views geben, die verschiedene
Ausschnitte einer Graphik zeigen.
Ausserdem: Bessere Trennung zwischen Model und View/Contoller im
Sinne von MVC moeglich. Da ViewObjekte gespeichert
werden, sind sie als Daten zu betrachten und damit
dem Model zuzuordnen und somit im Dokument (=Model einer
Anwendung) statt im View (= View+Controller einer Anw.)
zu speichern. Naeheres siehe Doku zu ET++.
- Views sollten keine Anwendungsdaten mehr enthalten (ViewObjekte).
ViewObjekte muessen in einen Anwendungsteil und einen Darstellungsteil
aufgespalten werden.
- Widgets sollten ueberhaupt keine Anwendungsdaten mehr enthalten. Diese
sollten alle im Dokument enthalten sein.
- create_windows sollte nach dem Initialisieren bzw. Laden des Dokumentes
aufgerufen werden, d.h. wenn die Fenster erzeugt werden stehen alle
Anwendungsdaten bereits zur Verfuegung. Vorteile sind:
1. read_from_stream() braucht sich nicht mehr um ein Update der Fenster
zu kuemmern (manchmal ist Update noch nicht moeglic, weil X-Windows
noch nicht erzeugt sind, etc.).
2. Die Fenster muessen nur einmal an die Anwendungsdaten angepasst
werden (sonst zweimal).
3. Insgesamt erhaelt man eine bessere Trennung zwischen Anwendungsdaten
und den Darstellungskomponenten und damit eine bessere innere Struktur
der Software.
- Es muss ein allgemeiner Change/Update-Mechanismus spezifiziert und
realisiert werden. Changed() & Update() ohne Parameter scheint zu allgemein
und fuehrt zu Ineffizienz. Wie soll parameterisiert werden ? Ueber
Vererbung mit Unterklassen von Observer und Observed ? Ueber Parameter,
also Changed(int reason, void *detail) etc. ? Oder gibt man nur
Richtlinien vor, und erlaubt dem Programmierer, problemangepasste
Changed(...) und Update(...) Funktionen zu schreiben ?
- GnDoubleLinkedList::_Position() implementieren.
Konstruktor GnDoubleLinkedListIterator(GnDoubleLinkedListIterator &) impl.
- generische, dynamische Arrays implementieren, evtl. auch mehrdimensional.
Claus Riemann ? Vorbild LEDA
- Fehlende META_IMPL bzw. ImplGeneric.. fuehren zu undefinierten vtbls.
- Im "Debug" Menu sollte ein Eintrag "Show Classes" sein, der in einem
GraphView (Andreas G.) die Klassenhierarchie anzeigt.
- Es sollten Namenskonventionen und Programmierrichtlinien aufgestellt
werden und GINA++ daran angepasst werden.
Robert 21.5.91
==============
- Text-Viewobjekt (Tastaturhandling) (Claus Riemann)
Robert 15.5.91
==============
- Cut & Paste muss eingebaut und erweitert werden zu
Publish & Subscribe: Links zwischen Dokumenten mit automatischer
Datenaktualisierung.
- virtuelle Funktionen sollten nicht Inline vereinbart werden,
da das je nach Technik des Includierens sehr viel Speicherplatz kosten kann.
Robert 6.5.91
=============
- Wir brauchen Mechanismen zur Synchronisation der Bearbeitung von
Dokumenten.
==============================================================================
Andreas (24.5.91)
- Fallback Resourcen anschliessen: Vorteil: man wird unabhaengig von .Xdefaults
- GINA++ als shared library ?
==============================================================================
Andreas (30.7.91)
- Collection Klassen von ET++ oder NIHCL integrieren ?!
- Read/Write Konzepte (Karl Heinz) ausprobieren
- Generizitaet ?
- Makros ?
- Type Cast ?
- Auf 3.0 warten ?
- Cut/Copy/Paste
- generisch loesen
- auch ueber Anwendungen hinweg
- Dokumente Save/Open
- Generisch (ohne write_to_stream)
- View-Objekte ueberarbeiten
- GnDirectM. und GnViewObject zu einer Klassen zusammenfassen.
- Postscript-Drucken
- XmSelectionBox/XmFileSelectionBox in abstrakte Selection-Klassen integrieren.