[Allegro] Kahlschlag!

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Everberg, liebe Liste,

Ich habe die einschlaegigen Verlautbarungen nun schon ziemlich oft
gelesen und allmaehlich beginne ich etwas zu verstehen:

aresqa (Allegro und SQL) ist realisiert durch die beiden Flexe
aresqa1.flx und aresqa2.flx, die in der Praxis ihre Tragfaehigkeit
noch beweisen muessen (derzeit wird z.B. Quatsch exportiert, wenn
man mit "&kkf" Kategorien als nicht zu reimportieren kennzeichnet).

aresqa als "Konzept" ist eigentlich das alte View-Fenster, nur dass die
Buttons nun links statt rechts sind, der Hintergrund weiss und die
Editierfunktionen leicht verbessert. Nur: Fuer das Handling von
*Tabellen*daten habe ich selten ein so ungeeignetes Werkzeug gesehen:
Das Fenster kennt keine Spalten und Tab als typischen Feldtrenner kann
man nicht eingeben... (Spalten hingegen waren schon immer ein Desiderat,
auch bei der normalen Kurzliste, von der die Viewlisten abgeleitet
sind).
[Fuer die neuerdings propagierte Nutzung zur Bearbeitung von
Parameterdateien ist das Fenster auch nicht wirklich praktisch, dazu
sind die DOS-spezifischen Sonderzeichen in typischen Parametern einfach
zu extrem, die wird man nie mit einem Windows-Programm in den Griff
bekommen...]

ViewListen als Konzept waren auch eine prima Sache, der urspruengliche
Plan (soweit ich ihn verstanden habe) war komplexe Sortierung von
Ergebnismengen mit der nachtraeglichen (bzw. vor der eigentlichen
Exportproduktion) Option, daraus Saetze zu eliminieren. Gerade
letzteres, also eine Eingriffsmoeglichkeit kurz vor Schluss, ist dann
irgendwann wieder herausgenommen worden: ViewListen wurden naemlich als
Fortsetzung des Menuesystems eingesetzt und Anwender zerschossen sich
mit der Entf-Taste regelmaessig die aus Braunschweig gelieferten
Standard-Menues...

Mit "Aresqa" haben wir nun eine dritte, leicht abweichende Methode, mit
der in a99 Benutzerfuehrung und Menues realisiert sind, ich weiss
wirklich nicht mehr, wem das nuetzen sollte (und was das mit SQL zu
tun hat).

Mein Vorschlag fuer v26 ist daher, sowohl die degenerierten ViewListen
als auch das postpartal degenerierte Aresqa komplett einzustampfen und
(diesmal ohne zusaetzlichen Jargon, der auch nur verwirrt) eine
moeglichst einheitliche Form von Listendarstellung zu schaffen.
Die darf m.E. durchaus sowohl fuer "echte" und aufbereitete (View)
Kurzlisten von Datensaezen als auch fuer Dateiuebersichten etc. genutzt
werden, und koennte auch ein "Schreibschutz"-Feature haben, wenn man sie
fuer Menues einsetzen moechte. Wichtig waeren verschiebbare Spalten
(z.B. aber auch unsichtbare Spalten, in denen man a la ViewListe Flexe
oder Satznummern hinterlegen kann), eingebaute (naja, es darf auch ein
Flex sein) Sortierfunktionen, die bekannten Moeglichkeiten der
Volltextsuche und des "Gehe zu Zeile" (vielleicht also sogar zwei
Eingabefelder spendieren?), die Moeglichkeit des manuellen Verschiebens
von Zeilen und ggfls. beschraenkte Editiermoeglichkeiten. Ueberschriften
des Fensters sollten durch speziell formatierte Zeilen in der
einzulesenden Datei eingestellt werden koennen, die Methode mit "set i",
die Ueberschriften "von aussen" zu setzen, hat sich als zu umstaendlich
erwiesen. Ziel sollte sein, dass solche Dateien (noch staerker als
ViewListen) aus a99 heraus direkt aufgerufen werden koennen und alle
Meta-Information ueber Darzustellendes und bei Klick Auszufuehrendes
bereits in sich tragen (Oder man arbeitet mit Dateipaaerchen, die
tabellarischen Rohdaten plus eine Datei mit Steuerinformation, das
koennte aber schnell wieder zu komplex werden). In der Darstellung waere
das Layout eines solchen Listenfensters absolut einheitlich, je nach
Kontext waeren allerdings gewisse Buttons dann als inaktiv "eingegraut".

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCw9pgENVh3bB0lwMRAkQMAJ9+fUQ5ZliMUOogOCIA5cVLhHWCAgCfe3b2
TMhvmtnKuZ19N5b1vGusivo=
=eipW
-----END PGP SIGNATURE-----