4.7 *** Pointer Environment

Das Pointer Environment ("PE"), die "Pointer Ausstattung", ist ein Hilfssystem der Fensterverwaltung in weitestem Sinne, das die QDOS-Grundinstallation ergänzt.

Es besteht aus einer Erweiterung des CON-/SCR-Handlers, dem Pointer Interface (Codefile "ptr_gen"), sowie dem Window-Manager ("wman") zur Unterstützung von Menustrukturen und schließlich dem Hotkey-System ("hot_rext") das eine Abwandlung und funktionale Ergänzung der vom TK2 bekannten ALTKEYs installiert. Außerdem ist darin neben dem Thing-System selber auch die Emulation der Thing-Traps für das QDOS enthalten.

Das Pointer Interface ("PIF") stellt die grundlegenden fensterbezogenen Programmteile dafür bereit.

Die Bedeutung für einen Pointer als Adresse einer Adresse wird im zugehörigen Text nun ausschließlich der Abkürzung "Ptr" vorbehalten sein. Pointer heißt derweil ein über den Bildschirm bewegbares Bildchen, dessen Position der Ort des Cursors ist. Es wird vornehmlich durch einr "Maus" gesteuert, aber ebenso auch durch die Cursortasten, und erhält zumeist, nicht zwingend, mit ENTER (linke Maus) eine aktivierende und mit SPACE (rechte Maus) eine auswählende Funktion.

Die Offsets in die Kanaldefinitionsblöcke beziehen sich im Folgenden auf deren Basisadresse, wie sie etwa innerhalb eines SD.EXTOP-Aufrufs gilt. Nach derzeitiger Definition liegen sie im QDOS um 48 Bytes über denen standardgemäßer Fenster. Wenngleich Änderungen unwahrscheinlich sind, sollte dieser Abstand, wo von Bedeutung, dennoch stets aus dem aktuellen System ermittelt werden, da die wirkliche und die in A0 gelieferte Adresse bereits in den existierenden Varianten von E-Software und SMSQ rsp SMSQ/E nicht einheitlich behandelt werden!
Näheres mag ggf. der Assemblerquelle zur PEX-Erweiterung entnommen werden.

Aus aktuellem Anlaß auch dies einschränkend zuvor:
Zur Zeit, da diese Texte in Arbeit waren, erschienen etwa monatlich neue und in den Änderungen gänzlich undokumentierte Versionen des PIF. Darum soll - und kann - nicht allzusehr in die Details gegangen werden. Die Allgemeingültigkeit wäre fragwürdig. Es ist sicher ratsam, alle Programmteile, die die folgenden Angaben nutzen, eingehend auf einwandfreie Funktion zu überprüfen. Das hier Dargestellte ist mit der PIF-Version 1.42 abgeglichen und einsetzbar.

Zum Zeitpunkt der 2. Überarbeitung (3. Auflage) lag das PIF in Version 1.71 vor. Eine ältere Version wurde re-assembliert und eingehenden Analysen unterzogen, einige der jüngeren Änderungen sind dem Autor aus anderen Gründen detailliert bekannt, und durch die Arbeiten an der PEX-Erweiterung hat er weitere Erfahrungen gewonnen. Dies alles jedoch rein empirisch, denn weiterhin gibt es von "offizieller" Seite keinerlei klare Beschreibung hierzu, auch das QPTR-Handbuch weist empfindliche Lücken auf.
Darum muß so manches wichtige Detail der Spekulation überlassen bleiben oder kann als Beschreibung des aktuellen Zustands gelten, nicht aber als für alle anderen Versionen gesicherte Angabe.
 

4.7.1 ** Pointer Interface

Im Pointer Interface liegen die grundlegenden IOSS-Aufrufe vor, auf denen das Pointer Environment basiert. Das sind die Aufrufe zum Öffnen, Schließen und Bedienen der Ein- und Ausgabe von Fensterkanälen neben den eigentlichen Pointer-Routinen. Parallel zu den Standard-Definitionen der SCR- und CON-Kanäle sind deren Handler-Definitionen erweitert worden und ermöglichen nun die Konservierung einander überschneidender Fenster. Zugleich wird mit der Kontrolle über die Funktion der CTRL/C-Taste ein bestimmbares Fenster zum Ort der Tastatureingabe gemacht. Ein Job wird auf diese Weise also auch durch ein Programm wählbar aktiviert. Erwartet der Job eine Tastatureingabe, wird der Pointer abgeschaltet, sein Bild verschwindet.

Leider gibt es eine stete Fehlerquelle, auf den gleich erst einmal aufmerksam gemacht werden soll:

Die Routinen des Pointer Interface übernehmen die zugehörige Speicherverwaltung beim Öffnen eines Primärfensters (s.u.) erst nach der ersten I/O-Operation. Sollten sonst irgendwelche Vorgänge in den Fenstern veranlaßt worden sein, gerät ihr Speicher durcheinander. Im Normalfall ist er dann für jeden weiteren Zugriff verloren und kann auch nicht mehr freigegeben werden.
Man kann jedoch durch z.B. PAPER 0 als erster Aktion im betr. Fenster jenes in die Verwaltung durch das PIF einreihen und so jedes diesbezügliche Risiko leicht und ohne Einfluß auf die Fenstergestalt ausschalten.
Solche Aktionen sind nur in Systemen mit integriertem PE (z.B. SMSQ/E) nicht erforderlich, dort übernimmt das PIF die Fenster sofort.
 

4.7.2 ** Fensterdefinition

Das einem I/O-Auftrag zuerst zugewiesene Fenster heißt "Primärfenster", alle weiteren Fenster desselben Jobs sind dann "Sekundärfenster".

Das Primärfenster umfaßt den gesamten Arbeitsbereich eines Jobs im Bildschirm, einschließlich irgendwelcher garnierender Linien oder Abschattungen. Mehrere Sekundärfenster können offen sein. Sie können nicht über die Grenzen eines Primärfensters hinausreichen, wie sie als Arbeitsbereich im Kanal-Definitionsblock angegeben sind. Wird dennoch ein Sekundärfenster definiert, das diese Grenzen überragt, wird der primäre Bereich entsprechend erweitert.

Dann gibt es einen Treffer-Bereich, "hit area", für den über den Bildschirm flitzenden Pointer, innerhalb dessen eine entsprechende Aktivierung erkannt wird. Dieser Bereich ist im erweiterten Kanal-Definitionsblock notiert. Er kann bis an die innere Grenze eines Primärfensters heranreichen. Der andere Bereich, "outline area", umfaßt das Primärfenster und hat ebenfalls einen besonderen Platz im Definitionsblock.

Zur Kontrolle dieser Struktur hat jedes Primärfenster noch die Ptr in eine nach beiden Richtungen durch alle seine Sekundärfenster gefädelte Liste in SD.PRWLB (-8, aufwärts) und SD.PRWLT (-4, abwärts).

Einander überschneidende Fenster werden wie ein Stapel von Zetteln nacheinander aufgeschichtet im "pile" gesammelt, einer besonders verwalteten Stackstuktur. Jedes auch nur teilweise überdeckte Fenster wird zunächst für den Zugriff versperrt, kann also in keiner Weise verändert werden. Ein Flagbyte in SD.WLSTT (16) wird entsprechend markiert.

Steht der Pointer auf dem sichtbaren Teil eines Fensters, läßt es sich durch Anwahl mit einer dazu bestimmten Taste aus dem Stapel herausziehen. Es gelangt dadurch an die Spitze des Pile und wird aktiviert. Das bis dahin aktive Fenster wird nun verdeckt. Mit der einleitend schon beschriebenen Auswahl eines Fenster durch Aktivieren der Eingabe geschieht das ohnedies. Anwählen eines anderen, zumeist eines Sekundärfensters, öffnet für dieses den Bildschirm. Wenn es ebenfalls eine Eingabe aufnehmen soll, wird wieder der Pointer ausgeblendet und die folgenden Zeichen aus der Tastatur werden dorthin geleitet.

Aus einer Anwendung heraus lassen sich auch eigene Fenster zudecken. Dies dadurch, daß das obere Fenster aus dem Pile hervorgeholt wird. Wobei das nur dann wirken kann, wenn das hervorgeholte Fenster das andere irgendwo überlappt.

Die nötige Zwischenspeicherung des Bildinhalts geschieht in einen Bereich, dessen Adresse im Definitionsblock auf SD.WSAVE (4) des Primärfensters angegeben ist. In SD.WSSIZ (8) steht die Größe des Bereichs, dazu noch das Flagbyte SD.MYSAV (19) für die Verriegelung. Eine Copie davon ist bei den Sekundärfenstern verzeichnet.

Namen und Offsets dieser zusätzlichen Daten sind im Tabellenteil angegeben und auch bei den Trap-Aufrufen nach Bedarf kommentiert. Für ausführliche Angaben wird auf die zugehörige Original-Dokumentation werwiesen.
 

4.7.3 ** Graphik

Auch hier ist die Darstellung in der zugehörigen Dokumentation von der Klarheit eines Orakels, manches konnte nur erraten werden. Drum Vorsicht.

Zusätzlich zu den bereits vorhandenen Graphikdarstellungen können besondere Objekte definiert und in Pixelkoordinaten beschrieben werden. Alle Objekte werden aus einer Anzahl von Grundelementen zusammengestellt. Diese sind in Form gewisser Datenstrukturen den entsprechenden Trap-Aufrufen anzugeben.

Beispielsweise:
 

I OP.WBLB	115	$73	Blob zeichnen
IOP.LBLB	116	$74	Linie aus Blobs zeichnen
IOP.WSPRT	118	$76	Sprite zeichnen
IOP.SPRY	119	$77	Blob pixelweise übermalen

"blob" ist ein Entenei oder sonst eine rundliche Figur

HINWEIS:
IOP.LBLB weist Fehler beim "clipping" auf, wenn die Linienkoordinaten über den oberen Bildrand hinausweisen. Dann kann der Aufruf aufgrund von Rechenfehlern in eine endlose Schleife geraten und durch fortwährendes Zeichnen der Linie Teile des Systems überschreiben, was unkalkulierbaren Schäden zur Folge hat.
 

4.7.3.1 * Graphikelemente

Der Reihe nach hier nun die einzelnen Elemente, aus denen die später zu beschreibenden Objekte gebildet werden.

Bei den Daten unterscheiden wir begrifflich die

Regelform

als einer intern einheitlichen Maßangabe, und die

Darstellungsform,

abhängig von der Bildschirmbetriebsart.

Formulierung - form

Die Form beschreibt als 16-Bit-Zahl die Darstellungsweise des folgenden Musters. Zwei weitere Bytes geben die Anpassung an die Darstellungsweise an. Das Erste gilt, wenn ein Sprite als Pointer abhängig vom Ablauf einer Zeitvorgabe gemacht werden soll. Mit dem Zweiten wird die Entzerrung unterschiedlicher Maßstäbe der Bildschirmachsen bestimmt.

Pointer aus Sprites können veränderlich gestaltet werden. Bei Verkettung mehrerer Sprites mit unterschiedlichen Zeitangaben wird erst das mit niedrigster Nummer für die Dauer seiner Zeit erscheinen, dann die Nächsten in Reihenfolge aufsteigender Numerierung. Am Ende der Kette beginnt die Anzeige mit der niedrigsten Nummer erneut.
 

Regelform		dazu Entzerrung
	$00FE	1:0,5
	$00FD	1:0,6
	$00FE	1:0,71
	$00FF	1:0,83
	$0000	1:1
	$0001	1:1,2
	$0002	1:1,4
	$0003	1:1,7
	$0004	1:2,0
QL-Darstellung
	$0100	4-Farb-Auflösung
	$0101	8-Farb-Auflösung
Zeit
	00	ohne Angabe, statisch
	1..$FF	Wartezeit in Vielfachen von ca. 20 ms

 
Anpassung bitweise zusammengesetzt:

	Byte	Bit	Wirkung
	00		ohne Veränderung
	01	0	x ausdehnen
	02	1	x stauchen
	04	2	y ausdehenen
	08	3	y stauchen

 

Größe - size

Eine Angabe in 16-Bit-Zahlen positiv und nicht Null, also 1 bis 32767, für jeweils beide Richtungen, horizontal (x) wie vertikal (y).

Wiederholungsabstand - repeat

Ein Muster von Objekten erfordert gelegentlich die Angabe des Abstandes, der gegenseitiges Überschreiben vermeidet. Zwei 16-Bit-Zahlen enthalten diesen Abstand für beide Richtungen. Es gilt der Wertebereich wie für die Größe.

Ursprung - origin

Der Abstand zur Pixelposition des Cursors wird in weiteren zwei 16-Bit-Zahlen festgelegt. Der Nullpunkt liegt auf der oberen linke Ecke des Objekts. Abweichungen nach links und oben zählen negativ.

Farbe - colour

Im Bit 0 einer 16-Bit-Zahl wird markiert, ob die Farbe grundsätzlich überschreibend (1) oder additiv wirken (0) soll. Mit den Bits 1 bis 15 in aufsteigender Folge für die Intensität als 5-stelligem Binärwert werden die Farben in Reihenfolge blau, rot und grün angegeben.
 

g r b	g r b	g r b	g r b	g r b	ü	Wertigkeit der Farbenbits
4	3	2	1	0	x	in Zweierpotenzen

 

Die Kombination

 

Bit 16 für Grünintensität	2^4	16
Bit 13 dto.	2^3	8
Bit 12 für Rotintensität	2^3	8
Bit 10 für Grünintensität	2^2	4
Bit 0 für deckende Färbung		1

 

codiert den deckend gelbgrünen Farbton der Intensität 36. Die volle Intensität aller Farben hat zusammen den Wert 93. Die Farbenbits bilden bei Schwarz-Weiß-Darstellung den Helligkeitswert.

Farbmaske in Regelform - colour pattern

Dies ist eine Angabe mit auf gerade Adressen justierter Länge. Dort wird jeder Bildpunkt, der die zuvor angegebene Farbe erhalten soll, an entsprechender Stelle durch ein gesetztes Bit markiert.

Jede Bildpunktzeile eines Objektes wird durch solch eine Bitmaske repräsentiert. Ein Datenblock definiert Farbe und Punkte für jeden Farbauszug (Farbfläche) des Objektes. Die Anzahl richtet sich nach der Zahl der darzustellenden Farben, soweit sie additiv gebildet werden. Sonst wird nur ein einziger Farbauszug wirksam; ein Block genügt.

Dem nur wenig aufschlußreichen Beispiel der Dokumentation zufolge werden die Farbauszüge von dem Datenblock an abgearbeitet, der an höchster Adresse steht. Was beim Überschreiben bereits eingefärbter Bildteile zu beachten ist.

Hier umschließt ein gelber Block mit 5x4 Pixel Regelgröße einen schwarzen Block der Größe 3x2:

dc.w 2 zwei Blöcke abzubilden
dc.w %1100000000000000 gelbe Farbe additiv
dc.w %1111100000000000 fünf Punkte der ersten Linie
dc.w %1000100000000000 zweite gelbe Linie
dc.w %1000100000000000 dritte dto.
dc.w %1111100000000000 letzte dto.
dc.w %0000000000000001 schwarz überschreibend
dc.w %1111100000000000
dc.w %1111100000000000 fünf gleiche Linien
dc.w %1111100000000000
dc.w %1111100000000000

Schreibmaske - pattern mask

Eine weitere, gleicherweise aufgebaute Maske kann einzelne Bits additiv färbend oder überschreibend definieren. Damit ist bedarfsweise die pauschale Farbenangabe modifizierbar. Weiß bedeutet Überschreiben, Schwarz additive Mischung.
 

4.7.3.2 * Graphikobjekte

Die Objekte werden nun in Gestalt von Tabellen angegeben, die im Einzelnen unterschiedliche Datengruppierungen der obigen Kathegorien enthalten.

Sprite

Form 2 Worte
Größe 2 Worte
Ursprung 2 Worte
Farbmaske rel Ptr auf die Tabelle als Langwort
Schreibmaske dto., oder Null
Verkettung dto. auf nächste Definition oder Null

Blob

Ein Blob wird bei Erhalt des eigenen Musters über den Bilschirm bewegt, seine Linien schließen sich ungebrochen aneinander an, sie werden nicht übermalt. Man mag sich den Bildschirm als übertapezierte Fläche vorstellen, in der die Blobs als Teile der alten Tapete beim Hochpellen der jeweiligen Bereiche sichtbar werden.

Dieselben Angaben wie für ein Sprite sind erforderlich.

Muster - pattern

In einem Muster ist jeder Bildpunkt einzeln in Farbe und Schreibweise definierbar. Es gilt ein Wiederholabstand in waagerechter und horizontaler Richtung.

Form 2 Worte
Wiederholung 2 Worte
Ursprung 2 Worte
Farbmaske Langwort rel Ptr auf die Tabelle
Schreibmaske dto.
Verkettung dto. zur nächsten Definition

Fläche - area mask

Mit einer Fläche werden die Grenzen eines Arbeitsbereiches definiert. Es sind mehrere solcher Tabellen möglich. Die hierzu erforderliche Anzahl Speicherbytes ist

2 + 6 * x_maß + 4 * (summe y_maße).

Es sind anzugeben:
 
 

	x_maß	Anzahl Tabellen
	y_maß	Länge dieser ersten Tabelle
	x_ursprung	Ursprung des Fenster-Teilbereiches
	y_ursprung	dto.
	tabelle	2 * y_maß Wortpaaren  mit unterer und oberer Grenze relativ zum Ursprung

 
Der Fenster-Teilbereich (z.B. als partial SAVE area) hat das Format:
 

	reserve	.l	Frei für die Anwendung
	$4AFC	.w	Marke (s. Anmerkung)
	x_maß	.w	Breite der Fläche in Bildpunkten
	y_maß	.w	dto., Höhe
	stufung	.w	Abstand in Bytes einer Linie zum Anfang der nächsten
	mode	.b	MODE des gesicherten Bildes
	reserve	.b	Null
	bild	stufung  * y_maß	die Datenbytes des Bildes

 
Die Marke $4AFC wird z.B. von den PIF-Traps iop.svpw erzeugt, und von iop.rspw erwartet, ist auch in den Hilfsdateien zu QPTR verzeichnet, fehlt aber im zugehörigen Handbuch. Man wird annehmen dürfen, daß dies einfach nur ein Druckfehler ist, und die Tabelle in obiger Form zutrifft.

 

=