view.txt V0.03, 04.05.1993 Das View-Protokoll ====================== Dies ist jetzt die erste 'offizielle' Version des View-Protokolls. Das View-Protokoll dient dazu, Dateien von einem sog. Viewer anzeigen zu lassen. Da es schon seit einiger Zeit solche Viewer gibt, z.B. GEM-View (von Dieter Fiebelkorn) oder 1st-View (von Guido Vollbeding), bieten schon einige Programme die Option an, Dateien von diesen Accessories anzeigen zu lassen. Dieter und ich haben nun das View-Protokolls entwickelt, um eine einheitliche Schnittstelle zu den verschiedenen Viewern zu bekommen, damit es moeglich wird, auch Dateien anzeigen zu lassen, wenn das Hauptprogramm den installierten Viewer nicht 'kennnt' (d.h. explizit unterstuetzt). Diese Version des Protokolls ist versuchsweise in GEM-View und ShowImage (mein Viewer) implementiert. Ueber Anregungen/Kritik etc. bin ich immer erfreut: Peter Seitz, Robert-Koch-Str.6, 6070 Langen (ab. 1.7.1993: 63225 Langen) E-Mail (Internet): seitz@rbg.informatik.th-darmstadt.de Im View-Protokoll werden einige Eigenschaften des XAcc-Protokolls ausge- nutzt. Es bietet sich daher an, sich eine XAcc-Docu zu besorgen. Peter 1. WER ist der Viewer??? ======================== - In dem Cookie 'View' steht ein Zeiger auf den vollstaendigen Pfadnamen des Viewers. Mit Hilfe von appl_find() kann nun festgestellt werden, ob der Viewer als ACC (oder unter MTOS auch als APP) geladen ist. Um appl_find() zu benutzen, muss erst der Pfad und die Extension entfernt und der Name auf 8 Zeichen mit Spaces aufgefuellt werden. Der Cookie wird von einem TSR installiert, z.B. VIEWINIT.TTP, das in den AUTO-Ordner kopiert werden kann. Hatte sich der Viewer noch nicht ueber XAcc angemeldet, holt die Applikation, die etwas angezeigt haben moechte, dies nun nach (vgl. XAcc- Dokumentation). Das ist der Fall, wenn die Haupt-Applikation kein XAcc unterstuetzt. Sollte der angegebene Viewer nicht installiert sein (appl_find() < 0) so handelt man so, als ob es den Cookie nicht gegeben haette. - Gibt es keinen 'View'-Cookie, ist aber eine XAcc2-Faehige Haupt-APP geladen (bzw. es gibt eine appl_search()-Funktion), so hat sich der Viewer ueber das XAcc2-Protokoll angemeldet. Dann muss man in den extended names nach '2View' (fuer application type) oder nach 'NView' suchen. Das ist dann der Viewer. 'View' wird dabei nur mit einem grossen 'V' geschrieben und NICHT ganz in Grossbuchstaben. - Das bedingt natuerlich, dass der Viewer die XAcc2 Basis-Messages versteht! Das ist allerdings eine Voraussetzung dafuer, dass er den Cookie anlegen (lassen) darf. - Ist der Viewer wirklich nicht geladen, aber der Cookie vorhanden, kann als letztes noch versucht werden, den Viewer selber nachzuladen. Dazu laedt man die im Cookie angegebene Datei mit den Dateien als Parameter. Unter MTOS kann man den Viewer (als ACC) nachladen. Vorsicht: Der Viewer wird eine GEM-Programm sein und Fenster oeffnen! 2. WAS kann ich anzeigen lassen? ================================ In den extended names sollte der Viewer als 'X.EXT' alle von ihm unterstuetzten Extension eintragen. Dass ist natuerlich nur ein Anhaltspunkt und noch etwas verbesserungsbeduerftig! Im Zweifelsfall probiert man einfach VIEW_FILE (s.u.) und guckt, was passiert! Fuer jeden Viewer sind alle anderen extended names, die mit 'X.' beginnen reserviert. Folgende Extensions bedeuten folgende Formate: .ART - Art-Director .ASC - Absaetze mit CR beendet, optional Zeilen mit LF .B&W - Imagelab Images .BLK - GFA-Bit-Block (6 Byte Header: Breite-1/Hoehe-1/Planes) .BMP - OS/2 Bitmap, MS-Window Bitmaps .CFN - Calamus Font .CRG - Calamus Raster .CTX - Calamus Text .CVG - Calamus Vektor .DOC - 1stWord Docs .DOO - Doodle Mono .ESM - Enhanced Simplex .FNT - GDOS - Fonts (und nix anderes) .GEM - GEM-Metafile .GIF - GIF Images .GVW - Sollte das dabei stehen (ist das nur intern benutzt?) .HEX - Hex-Dump <== Das ist nicht direkt eine Ext., gilt aber als Kennung .IFF - IFF-File (nur ILBM ???) .IMC - Signum!2 Images .IMG - GEM-Images, XIMG .JPG - JPEG Images .MAC - MacPaint Images .NEO - Neochrome Images .PAC - STAD Images .PC[123] - Degas compressed Images .PCX - PC Paintbrush .P[BGP]M - Portable Bit Map .PIC - Screen-Dump (in der akt. Aufloesung...?) .PI[123] - Degas uncompressed Images .RLE - MS-Window Bitmaps .RSC - GEM Resource Files .SNP - Becker Snap Shot (6 Byte Header: Breite/Hoehe/Planes) .SP[CU] - Spectrum 512 .SUN - Sun Rasterfiles .TGA - Targa Images .TIF - TIFF Images .TN[123Y] - Tiny Images .TXT - ASCII-Text (Zeilen mit CR/LF beendet, optional auch nur LF oder CR) .XBM - X Bitmap File ... Damit diese Kennungen eindeutig bleiben, sollte jeder, der noch etwas anderes anzeigen kann, dies mir mitteilen (Adresse s.u.). 3. WIE bekomme ich was angezeigt? ================================= - Dank XAcc2-Protokoll, weiss man sofort, ob und welche Message-Gruppen unterstuetzt werden. Die Gruppe 2 (IMG, Meta) bietet sich natuerlich an. Und Gruppe 1 mit Text und Tasten finde ich auch einsichtig. Die Tasten sollten vom Viewer als Eingabe interpretiert werden, d.h. ^O oeffnet ein neues Fenster! - Man sendet dem Viewer eine VIEW_FILE Message (s.u.). Damit hat man dann die besten Kontroll-Moeglichkeiten. Der Viewer unterstuetzt diese Message(s), nur dann, wenn '2View' oder 'NView' in dem ext.name steht. Das sollte aber der Fall sein! - Der Viewer muss (=sollte) VA_START verstehen (Protostatus testen!). Was er mit dem File anfaengt, muss er dann selber sehen; es wird auch keine Antwort verschickt. - Drag&Drop wird nicht speziell unterstuetzt. Natuerlich bleibt es jedem Viewer offen, auch dieses zu unterstuetzen. Geht dann aber wohl nur unter MiNT - ausprobieren (falls da nix besseres festgelegt wird). - Weitere Protokolle koennen darueberhinaus auch benutzt werden, falls diese eine Moeglichkeit bieten, herauszubekommen, ob man sie versteht. Achtung: Wenn ein Zeiger (z.B. auf den File-Namen) mit einer Message versendet wird, so MUSS dieser in einen global-lesbaren Speicherbereich zeigen! 4. Was tut der Viewer? ====================== - Bei Messages des XAcc-Protokolls (falls unterstuetzt) laeuft alles wie gewohnt. (z.B. ACC_ACK an Absender) Bekommt man ACC_KEY(^O = 0x184F,4 glaub' ich), sollte auf jeden Fall ein Fileselector + neues Fenster erscheinen (halt wie normal). Nebenbei: Zum verschicken von Texten/Bilder via XAcc wuerde ich Alternate-X vorschlagen (damit das einheitlich ist!). - Hat man eine VA_START-Message bekommen, so muss der Viewer selber heraus- finden, welches Format der File (bzw. die Files) haben, und sehen, ob er damit was anfangen kann. Der Absender hat aber keine Moeglichkeit herauszubekommen, was passiert. Benoetigt man weitere Informationen, sollte man stattdessen VIEW_FILE benutzen. 5. Die VIEW_xxx - Messages ========================== Dies ist das eigentliche View-Protokoll. Im Unterschied zu VA_START und den XAcc-Messages, hat man so weiteren Einfluss auf das, was mit dem dar- gestellten File passieren soll. Der Pfeil (-> bzw. <-) vor dem msg[0] Kennzeichnet, wer die Message verschicken kann. -> Eine Applikation sendet dem Viewer, <- Der Viewer dieser Applikation was sendet. <-> Diese Message kann jeder senden (toll!) Um einen File anzeigen zu lassen sendet man an den Viewer: -> msg[0] = VIEW_FILE msg[3/4] = filename msg[5/6] = 0 // reserviert msg[7] = 0 // 0 = neues Bild, sonst s.u. Dabei sollte man darauf achten, dass der filename auch global lesbar ist. Das ist bei der Verwendung von MiNT mit Memory Protection unumgaenglich!! Der Viewer antwortet darauf, wobei in msg[3/4] immer der bei VIEW_FILE uebergebene Filename steht (als Kennung), a) wenn das Bild nicht angezeigt werden konnte mit <- msg[0] = VIEW_FAILED msg[3/4] = filename msg[5] = errcode // s.u. msg[6] = 0 // reserviert msg[7] = 0 // neues Bild wobei >errcode< ein GEMDOS-Fehler (< 0) sein kann oder VIEWERR_ERROR - Nicht naeher bestimmter Fehler VIEWERR_SIZE - Falsche Groesse, z.B. zu gross VIEWERR_COLOR - Nicht unterstuetzte Aufloesung/Farbe VIEWERR_WID - Falsche Fenster-Kennung (s.u.) Damit ist die Kommunikation beendet. Diese Version des View-Protokolls duerfte wohl fuer JEDEN Viewer sehr leicht zu implementieren sein!!! b) wenn das Bild angezeigt wurde, aber keine weitere Kommunikation erfolgen soll, sendet der Viewer <- msg[0] = VIEW_OPEN msg[3/4] = filename msg[5] = 0 // bzw. viewprot_version msg[6] = 0 // reserviert msg[7] = 0 // keine Kennung! Damit ist das Bild zwar angezeigt, die Komm. aber trotzdem beendet. c) wenn das Bild angezeigt wurde und weitere Komm. moeglich ist, sendet der Viewer <- msg[0] = VIEW_OPEN msg[3/4] = filename msg[5] = viewprot_version msg[6] = 0 msg[7] = wid Dabei ist >wid< die AES-Kennung des Fensters, in dem das Bild ange- zeigt wird. Die aktuelle viewprot_version ist 0! Nun koennen sich die Applikation und der Viewer weitere Nachrichten zu dem Bild senden. Dabei steht in msg[7] IMMER die bei VIEW_OPEN uebergebene Fenster- Kennung >wid<. Dadurch kann man sich ueber meherer Bilder 'unter- halten' ohne durcheinander zu kommen. Sollte der Viewer eine falsche Fenster-Kennung erhalten, so sendet er eine VIEW_FAILED-Message mit msg[7] = der falschen Kennung und msg[5] = VIEWERR_WID, msg[3/4] sollte den Datei-Namen enthalten. Eine wid <= 0 ist auch ungueltig (bzw. reserviert)! Eine Message mit falsche Kennung darf fuer den Viewer keine Auswirkungen haben. Der Empfaenger des VIEW_FAILED(VIEWERR_WID) sollte aber diese Kennung als ungueltig vermerken und keine weiteren Messages mit dieser wid senden. Das kann der Fall sein, wenn kein VIEW_CLOSED(wid) gesendet wurde. Generell sollte der Viewer auf alle View-Messages antworten. Der Absender muss aber damit rechnen, dass die Antwort ausbleibt (aus welchem Grund auch immer). Das Ausbleiben sollte wohl als ein VIEWERR_ERROR gewertet werden, falls die Antwort wichtig ist. Es muss auch damit gerechnet werden, dass vor der Antwort andere Messages eintreffen (z.B. AV_ACCWINDOPEN oder sowas)! Ist das File angezeigt (und weitere Kommunikation moeglich), kann man diesen nun auch weiter beeinflussen: * Die Applikation moechte, dass das Bild-Fenster wieder geschlossen (und der File aus dem Speicher entfernt) wird. -> msg[0] = VIEW_FILE msg[3/4] = 0 // d.h. entfernen! msg[5/6] = 0 msg[7] = wid // die ID des Fensters wid = 0 ist nicht sinnvoll und sollte ignoriert werden! * Das Fenster wird geschlossen. Das kann auf Grund des VIEW_FILE(0) sein, oder auch weil der Benutzer es zu gemacht hat oder der Viewer AC_CLOSE bekommen hat oder terminiert oder so... <- msg[0] = VIEW_CLOSED msg[3/4] = filename // optional, darf auch NULL sein!! msg[5/6] = 0 msg[7] = wid falls irgendein Fehler die Ursache des Schliessens war kann der Viewer auch <- msg[0] = VIEW_FAILED msg[3/4] = filename // optional, darf auch NULL sein!! msg[5] = errcode // s.o. msg[6] = 0 msg[7] = wid senden. Anhand von >wid< erkennt man (in beiden Faellen), welches Fenster geschlossen wurde. >filename< koennte z.B. dazu gebraucht werden, in einer Mitteilung (an den Benutzer) zu erscheinen. Man sollte jedenfalls damit rechnen, dass >filename< (falls angegeben) ein anderer ist, als der bei VIEW_FILE gesendete. Neu ab 13.04.1993: Der Einfachheit halber, kann VIEW_CLOSED entfallen, wenn es nicht als Reaktion auf eine View-Message erfolgt. Dadurch braucht der Viewer sich die ap_id des Senders nicht zu merken und kann einfach nur auf Messages reagieren. Das kann natuerlich zu Fehlern fuehren, falls eine andere APP ein Bild anzeigen laesst und zufaellig die gleiche wid bekommt. ==> Mal probieren ob's auch so geht! (-> Kommentare!?) * Hat man aus zuverlaessiger Quelle erfahren, dass sich der angezeigte File geaendert hat (oder moechte man einen anderen File im selben Fenster anzeigen lassen) sendet man: -> msg[0] = VIEW_FILE msg[3/4] = filename // kann geaendert sein! msg[5/6] = 0 msg[7] = wid // die Kennung des Fensters Hierauf wird der Viewer den File >filename< in seinem Fenster >wid< darzustellen versuchen und wie bei einem 'normalen' VIEW_FILE ueber den Erfolg berichten. In msg[7] steht dabei natuerlich >wid<. Es ist auch moeglich, dass der Viewer als Reaktion hierauf statt der Aenderung, das Fenster schliesst und ein neues mit dem neuen File (und einer neuen Kennung) oeffnet. In diesem Fall erhaelt man VIEW_CLOSED(old_wid), VIEW_OPEN(new_wid). * Sollte ein Neuzeichnen des Fensters von Noeten sein (warum auch immer), so kann man es auf gewohnte Weise erreichen: msg[0] = WM_REDRAW msg[3] = wid msg[4-7] = fullx/y/w/h Da man die wahre Ausdehnung des Fensters nicht kennt, benutzt man die (max.) Groesse des Desktops stattdessen. Zusammenfassung: ---------------- Der Viewer bekommt immer nur VIEW_FILE gesendet. - msg[7] == 0 ? (Neues Bild) - Fehler -> VIEW_FAILED(wid = 0) senden - OK -> VIEW_OPEN(wid = 0) senden - OK + Kommunikation -> VIEW_OPEN(wid != 0) senden - msg[7] != 0 ? - msg[7] ist eine gueltige wid - msg[3/4] == 0 ? (Entfernen) - VIEW_CLOSED/VIEW_FAILED(wid = msg[7]) senden - msg[3/4] != 0 ? (Aendern) - VIEW_CLOSED/VIEW_FAILED(wid = msg[7]) senden - msg[7] ist Bloedsinn (z.B. < 0) - VIEW_FAILED(VIEWERR_WID, wid = msg[7]) senden Is' doch gar nich' so kompliziert, gell :-) d) Bild-Lade-Treiber etc. ------------------------------------------------ Wir sind dabei, auch Messages zu definieren, mit deren Hilfe es moeglich sein wird, Lade-Treiber (fuer weitere Datei-Formate) zu realisieren. Wer Interesse daran hat, kann mit uns gerne Kontakt aufnehmen. --------------------------------------------------------------------------- 6. Message-IDs ============== Zum Schluss noch die Defines. #define VIEW_FILE 0x5600 #define VIEW_FAILED 0x5601 #define VIEW_OPEN 0x5602 #define VIEW_CLOSED 0x5603 /*#define WM_REDRAW 20*/ #define VIEWERR_ERROR 0 #define VIEWERR_SIZE 1 #define VIEWERR_COLOR 2 #define VIEWERR_WID 3 // 0x56 - 'V' wie in 'View' !!! Alle weiteren Messages von 0x5600 bis 0x56FF bleiben fuer Erweiterungen reserviert!!