Anleitung zu Maus-Window V1.32 (Stand: 01.11.1994)
--------------------------------------------------
1. Was ist Maus-Window?
-----------------------
Wer schon einmal unter X11 gearbeitet hat, wird festgestellt haben, daž
immer das Fenster aktiv ist, das sich unter dem Mauszeiger befindet
(aužer man hat den Window-Manager anders konfiguriert). Ein „hnliches
Verhalten des ATARI-GEM w„re in mancher Hinsicht wnschenswert. Leider
ist es nur m”glich, dies durch ein "Toppen" des betreffenden Fensters
zu erreichen (sonst w„ren tiefgreifende Žnderungen im Betriebssystem
notwendig). In diesem Zusammenhang fand ich einen Artikel in einer
Fachzeitschrift fr den ST, der ein solches Programm zum automatischen
Toppen eines Fensters beschrieb. Leider war das Ergebnis nicht recht
berzeugend, da alle vorgestellten Methoden nicht zu vernachl„ssigende
Nachteile auswiesen. Also begann ich, ein eigenes Programm fr diesen
Zweck zu erstellen. Das Ergebnis ist das hier vorliegende Programm Maus-
Window, das als Accessory in das Wurzelverzeichnis des Bootlaufwerks
kopiert werden muž. Der Betrieb als Programm ist auch m”glich, hat aber
nur in einer Multitasking-Umgebung Sinn. Maus-Window l„uft brigens
ohne Probleme in beiden Modi unter MultiTOS, MagiC und Geneva.
Ist Maus-Window aktiv und der Mauszeiger befindet sich ber einem nicht-
aktiven Fenster, wird dieses automatisch in den Vordergrund bef”rdert.
Dazu wird die AES-Funktion appl_tplay benutzt, was eine 100%ig GEM-
konforme L”sung darstellt und mit allen "sauberen" Programmen
problemlos funktioniert (zu Problemf„llen siehe Punkt 4).
Haben die AES eine Versionsnummer gr”žer oder gleich 3.31, oder ist
WINX ab Version 2.1 installiert, benutzt Maus-Window den erweiterten
Funktionsumfang zum Bestimmen des "Eigentmers" des betreffenden
Fensters und schickt diesem dann die Meldung, daž das Fenster getoppt
werden soll.
Unter MultiTOS sorgt Maus-Window auf Wunsch auch dafr, daž der Prozež
mit dem obersten Fenster eine h”here Priorit„t erh„lt, was etwas
flssigeres Arbeiten erm”glicht.
Seit Version 1.20 ist Maus-Window bilingual, besitzt also deutsche und
englische Dialoge. Ist die Sprache des benutzten Rechners eine andere
als Deutsch, werden englische Dialoge dargestellt. Wer jedoch auch als
Deutscher die englischen Dialoge bekommen m”chte, sollte sich einen
_AKP-Cookie anlegen (n„heres zu dessen Format steht in der ST-Computer
04/93 auf Seite 89) oder unter MultiTOS in der Datei GEM.CNF die
Variable AE_LANG enstprechend um„ndern (Falcon-Besitzer k”nnen sich ja
sowieso durch diverse Programme die gewnschte Systemsprache im nicht-
flchtigen RAM einstellen). Dies hat gegenber einer entsprechenden
Option fr Maus-Window den Vorteil, daž davon auch viele andere
Programme beeinflužt werden und ihre Texte nicht mehr in Deutsch
darstellen.
2. Die Einstellm”glichkeiten von Maus-Window
--------------------------------------------
Ruft man im Accessory-Betrieb den Eintrag von Maus-Window im Desk-Men
auf, so erscheint ein Dialogfenster (was beim Betrieb als Programm nach
Anwahl des Menpunkts "Parameter: einstellen..." geschieht). In der
"Parameter"-Box k”nnen mehrere Einstellungen vorgenommen und auf Wunsch
gespeichert werden, die das Verhalten von Maus-Window beeinflussen.
Alle Žnderungen, die man in diesem Fenster vornimmt, treten sofort in
Kraft, der Button "OK" ist nur zur entgltigen šbernahme der
Einstellungen gedacht (der Dialog ist also wie das ATARI-Kontrollfeld
nicht-modal).
Folgende Optionen bietet Maus-Window:
"Maus-Window aktiv":
Legt fest, ob Maus-Window Fenster toppen soll oder nicht.
"Nur im Arbeitsbereich":
Ist diese Checkbox angekreuzt, werden Fenster nur dann nach vorne
geholt, wenn sich der Mauszeiger ber dem Arbeitsbereich des Fensters
befindet (unter WINX < 2.1 k”nnten sonst versehentlich die
Rahmenelemente bedient werden, da Maus-Window bei AES-Versionen kleiner
3.31 ja einen Mausklick simuliert). Diese Option eignet sich auch
dafr, wenn man unter WINX >= 2.1 oder MultiTOS problemlos die
Fensterelemente hinten liegender Fenster erreichen will (ohne muss man
schon etwas Glck haben, daž das Fenster nicht vorher getoppt wird).
"'Verschwinden' verhinden":
Legt fest, ob darauf geachtet werden soll, daž keine Fenster nach vorne
geholt werden, die das momentan oberste komplett verdecken wrden (oder
nur dessen Arbeitsbereich, je nach Einstellung von "nur im
Arbeitsbereich").
"Nicht w„hrend Bewegung toppen":
M”chte man nicht, daž Maus-Window auch w„hrend der Bewegung des
Mauszeigers Fenster "toppt", sollte man diese Checkbox ankreuzen.
"Wartezeit: ... ":
Diese Option sorgt dafr, daž ein Fenster erst dann getoppt wird, wenn
der Mauszeiger sich bereits eine bestimmte Zeit ber diesem aufgehalten
oder stillgestanden hat (abh„ngig von der Einstellung der vorherigen
Option). Die Zeitspanne wird in ds (also 10tel Sekunden) angegeben und
kann mit den beiden Pfeilen im Bereich von 1-99 eingestellt werden
(Doppelklicks „ndern den Wert in Zehnerschritten, auch die Cursortasten
k”nnen benutzt werden).
"Erst nach Mausbewegung toppen":
Auch wenn es im ersten Moment so den Anschein hat: Dies steht nicht im
Widerspruch zum vorletzten Absatz, aber leider ist mir keine bessere
Kurzbeschreibung des Sachverhalts eingefallen... Ist diese Option
aktiviert, wartet Maus-Window nach einem Wechsel des obersten Fensters
solange mit dem Toppen des n„chsten, bis die Maus bewegt wurde. Dazu
ein Beispiel: Man hat in einem Programm zwei Fenster offen, der
Mauszeiger befindet sich ber Fenster 1, das somit auch oben ist. Jetzt
aktiviert man per Tastatur Fenster 2 (z.B. durch CTRL-W). W„re die
Option nicht aktiv, wrde Maus-Window bei der n„chsten Gelegenheit
wieder Fenster 1 toppen, was ja eigentlich nicht unbedingt erwnscht
ist. Auf diese Weise wird erreicht, daž Fenster, die per Tastatur
aktiviert wurden, auch wirklich erstmal oben bleiben. Auch beim
Backdrop eines Fensters unter MultiTOS oder WINX sorgt diese Option
dafr, daž man auch das erreicht, was man wollte... Es ist zweckm„žig,
zus„tzlich "Nicht w„hrend Bewegung toppen" zu aktivieren.
"Fensterlose Prog. schtzen"
Unter Multitasking-Umgebungen kann ein Fensterwechsel auch einen
Applikationswechsel zur Folge haben, wobei auch die Menleiste
umgeschaltet wird. Mit der Option "Fensterlose Prog. schtzen" kann nun
dafr gesorgt werden, daž Maus-Window nicht toppt, wenn die
Applikation, deren Menleiste gerade aktiv ist, keine Fenster offen
hat. Der Sinn liegt darin, daž sonst ja die Menleiste des Programms
weg w„re und man mangels Fenster nur noch durch Umschalten der
Applikation an das Programm k„me. Wenn die AES es untersttzen, prft
Maus-Window zus„tzlich, ob das zu toppende Fenster einem Accessory
geh”rt, wenn ja, wird es doch getoppt, da ein Accessory keine eigene
Menleiste hat. Es ist leider nicht m”glich, auch zu prfen, ob das
Programm, dem das zu toppende Fenster geh”rt, berhaupt eine Menleiste
besitzt; daher k”nnen nur Accessories bercksichtigt werden.
"Fensterlose Prog. schtzen" ist nur w„hlbar, wenn die AES mehr als
eine Applikation erlauben (Multitasking) und den erweiterten menu_bar-
Aufruf bereitstellen. Das Bercksichtigen der Acceossry-Fenster ist nur
m”glich, wenn die AES den appl_search-Aufruf untersttzen. Beides ist
bei MultiTOS, MagiC und Geneva der Fall.
"Priorit„t fr oberstes Fenster":
Diese Option ist nur w„hlbar, wenn unter MultiTOS gearbeitet wird (fr
Experten: Maus-Window muž auch mit Root-Rechten laufen). Ist sie aktiv,
erh„lt der Prozež, dem das momentan oberste Fenster geh”rt, eine h”here
Priorit„tsstufe, damit mit ihm besser gearbeitet werden kann. Die
Priorit„t wird auf den alten Wert zurckgesetzt, wenn ein anderer
Prozež das oberste Fenster erh„lt.
"Nur Mausklick simulieren":
Wie unter Punkt 4 beschrieben, kann es unter KAOS und/oder NVDI 1.x
passieren, daž der Mauszeiger an den linken Bildschirmrand springt,
wenn ein Fenster getoppt werden soll. Mit dieser Option l„žt sich das
Problem beseitigen, Maus-Window simuliert dann tats„chlich nur noch
einen Mausklick, w„hrend im Normalfall der Mauszeiger so positioniert
wird, daž der simulierte Mausklick auch das richtige Fenster trifft. Es
ist ratsam, zus„tzlich die Option "Nicht w„hrend Bewegung toppen" zu
aktivieren, da es sonst w„hrend schneller Mausbewegungen passieren
kann, daž sich der Mauszeiger beim simulierten Klick bereits nicht mehr
ber dem betreffenden Fenster befindet. "Nur Mausklick simulieren" ist
nicht anw„hlbar, wenn unter AES >= 3.31 oder WINX >= 2.1 gearbeitet
wird, da hier nicht per Simulation eines Mausklicks getoppt wird.
Desweiteren l„žt sich festlegen, bei welchen Sondertasten (Shift
links/rechts, Control und Alternate) keine Fenster aktiviert werden
sollen, wenn mindestens eine davon gedrckt ist (gedrckte Maustasten
bewirken dies grunds„tzlich auch).
M”chte man die get„tigten Einstellungen als Standard bei Programm- bzw.
Accessory-Start haben, so kann man mit "Sichern" den Parametersatz als
MAUSWIND.INF im gleichen Verzeichnis, in dem sich Maus-Window befindet,
abspeichern. Diese Datei wird von Maus-Window bei jedem Start
ausgewertet, ist sie nicht vorhanden, werden alle Optionen aktiviert.
Mit "OK" werden die Einstellungen bernommen und der Parameterdialog
verlassen. "Abbruch" stellt zuvor noch den alten Parameterzustand
wieder her. Der Button "Info" ruft ein Dialogfenster mit einer
Kurzinformation auf, das mit einem Klick auf "OK" wieder verlassen
werden kann.
3. Maus-Window "light"
----------------------
Da es zur Zeit ja beinahe notwendig ist, zu jedem Produkt auch eine
"light"-Version anzubieten, habe ich das auch bei Maus-Window gemacht:
Die "light"-Variante ist wesentlich krzer (nur ca. 18 Prozent der
Normalversion), bietet keine Online-Einstellungsm”glichkeit und l„uft
nur als Accessory.
Maus-Window "light" bercksichtigt wie sein grožer Bruder die Datei
MAUSWIND.INF, l„žt es aber nur zu, Maus-Window global ein- und
auszuschalten. Dazu erscheint bei Anwahl des Desk-Men-Eintrags eine
Alertbox mit den Auswahlm”glichkeiten "an" und "aus", mehr nicht.
Maus-Window "light" ist also fr all diejenigen gedacht, die den ganzen
Parameterschnickschnack nur einmal einstellen und danach lieber die
wesentlich speicherfreundlichere Variante benutzen wollen.
4. Problematische Programme
---------------------------
Wie bereits erw„hnt, ist Maus-Window 100%ig GEM-konform. Allerdings ist
es darauf angewiesen, daž auch die laufenden Programme nach den
Richtlinien programmiert sind. Maus-Window bleibt bei allen Programmen
wirkungslos, die keine echten GEM-Fenster benutzen (z.B. „ltere
Versionen von CyPress) oder die AES-Nachrichten nicht oder nicht
richtig auswerten. Desweiteren gibt es Programme, die gewisse Annahmen
ber das Verhalten von GEM machen, die nicht dokumentiert sind. Auch
diese sind potentielle "Nicht-Funktionierer". Leider geh”rt zu ihnen
auch Pure C 1.0 (mit dem Maus-Window erstellt wurde): Ruft man mit der
Help-Taste das Hilfesystem von Pure C auf, ”ffnet sich ein Fenster. Ist
dabei der Mauszeiger gerade ber einem Quelltextfenster, wird dieses
von Maus-Window nach oben geholt, was Pure C jedoch ignoriert. Es geht
weiterhin davon aus, daž sich das Hilfefenster oben befindet und gibt
den Hilfstext in das aktive Fenster aus. Dabei ger„t auch noch die
interne Fensterverwaltung von Pure C durcheinander, was dazu fhrt, daž
der Quelltext verloren ist. Mit Pure C 1.1 drfte das Problem nicht
mehr auftreten, da die Fensterverwaltung drastisch berarbeitet wurde.
Mit der Option "erst nach Mausbewegung toppen" l„žt sich dieses Problem
umgehen.
Wem weitere Programme auffallen, die sich mit Maus-Window nicht
vertragen, sollte mir schreiben (meine Adresse steht unter Punkt 5).
Ich fhre dann eine entsprechende Liste, die ich jedem zuschicke, der
mir einen an sich selbst adressierten, frankierten Rckumschlag schickt
oder sie per Email anfordert. Die Autoren solcher Programme sollten
wissen, daž diese sich mit hoher Wahrscheinlichkeit auch mit MultiTOS
und anderen Multitasking-System oder mit WINX nicht vertragen, was ein
Umprogrammieren wohl sinnvoll macht.
Probleme gibt es auch mit Programmen, die es erlauben, Fensterdialoge
im Hintergrund mit der linken Maustaste zu benutzen, auch wenn kein AES
>= 4.0 bzw. WINX >= 2.1 vorhanden ist. In diesem Fall kann Maus-Window
die Fenster nicht toppen, sondern bedient im ungnstigsten Fall den
gerade unter der Maus liegenden Button des Fensterdialogs. Abhilfe
hierzu gibt es leider nicht, man muž bei solchen Programmen halt darauf
achten, Maus-Window mit einer Sondertaste am Topversuch zu hindern.
Letztendlich ist es allerdings ein Fehler der Programmierer, da sie die
Meldung, daž ein Fenster getoppt werden soll, nicht korrekt auswerten.
Bei Applikationen, die ihre Fenster mit neueren AES-Versionen per
WF_BEVENT im Hintergrund bedienbar machen, wird Maus-Window diese
Fenster problemlos toppen, was allerdings auch nicht immer erwnscht
sein drfte. Auch hier gilt: Mit einer Sondertaste Maus-Window tempor„r
deaktivieren.
Ich habe bereits von mehreren Leuten, die KAOS und/oder NVDI 1.x laufen
haben, geh”rt, daž Maus-Window nicht korrekt toppt. Stattdessen wird
der Mauszeiger an den linken Bildschirmrand gesetzt. Ich weiž leider
nicht, woran das liegt, es ist allerdings sehr naheliegend, daž Maus-
Window unschuldig ist, da wie bereits erw„hnt nur appl_tplay zum
Simulieren des Mausklicks benutzt wird. Um sicher zu gehen, daž der
Mauszeiger sich dabei noch ber dem richtigen Fenster befindet, enth„lt
der appl_tplay-Aufruf auch mehrere Positionierungsanweisungen (v”llig
legal!) Anscheinend enth„lt KAOS und/oder NVDI 1.x in den von
appl_tplay intern benutzten VDI-Routinen einen Fehler, der dazu fhrt,
daž das Positionieren der Maus schiefgeht. Abhilfe schafft hier der
Einsatz von MultiTOS und/oder WINX ab Version 2.1, da Maus-Window hier
das Toppen der Fenster anders realisiert, oder das Aktivieren der
Option "nur Mausklick simulieren". Ob letzteres auch wirklich hilft,
kann ich mangels Testm”glichkeit leider nicht sagen, es ist auf jeden
Fall sehr wahrscheinlich.
Žltere Versionen von Mag!X 2.0 haben anscheinend ein Problem beim
Ausklappen von Mens: es wird manchmal kein wind_update(BEG_UPDATE)
aufgerufen, was u.a. dazu fhrt, daž Maus-Window bei ausgeklappten
Mens Fenster toppt. Wie das aussieht, kann sich jeder vorstellen... In
den neueren Mag!X-Versionen (> 2.0, heižt ja jetzt MagiC) sollte dieser
Fehler nicht mehr auftreten. Einige Betatester haben auch berichtet,
daž sich Maus-Window nicht aus dem Ordner \AUTO\APPS starten l„žt.
Seltsamerweise war das nicht bei allen so, deswegen kann ich dazu keine
verl„žlichen Angaben machen. Probieren geht hier ber Studieren...
Bei Benutzung von Geneva gibt es Probleme mit den Fenstern der Tear-
Away-Mens: Sie geh”ren laut wind_get der Applikation selbst, da diese
aber von der Existenz dieser Fenster nichts weiž, wird die von Maus-
Window verschickte WM_TOPPED-Nachricht nicht richtig ausgewertet. Im
gnstigsten Fall wird sie entweder einfach ignoriert (sauberes
Programm) oder das Fenster trotzdem getoppt, im schlechtesten strzt
das Programm ab, weil es z.B. verzweifelt versucht, das Fenster in
seiner Fensterverwaltung zu finden. Bis jetzt weiž ich leider nicht,
wie ich dieses Problem l”sen kann, vielleicht kann ja einer der Geneva-
Besitzer etwas dazu sagen.
5. Kontakt mit dem Autor
------------------------
Wer die Liste mit problematischen Programmen haben, seine Meinung
loswerden oder Vorschl„ge/Bugreports machen will, sollte sich an diese
Adresse(n) wenden:
Thomas Binder
Johann-Valentin-May-Straže 7
64665 Alsbach-H„hnlein
InterNet: binder@rbg.informatik.th-darmstadt.de
IRC: Gryf
Wer meint, Maus-Window sei so toll, daž er mir unbedingt eine kleine
Spende zukommen lassen muž, sollte diese Bankverbindung benutzen...
Dresdner Bank AG Frankfurt/Main
Konto-Nr. 9 024 050 00
BLZ 500 800 00
Im Klartext: In Maus-Window steckt inzwischen eine Menge Arbeit, ich
m”chte es jedoch trotzdem weiterhin frei kopierbar lassen. Daher f„nde
ich es sehr nett, wenn mir jeder, der Maus-Window regelm„žig benutzt,
eine kleine Anerkennung zukommen lieže. Dies wrde mich aužerdem
zus„tzlich anspornen, Maus-Window zu DEM Auto-Window-Topper fr den
ATARI zu machen.
6. Zum Kopieren von Maus-Window
-------------------------------
Maus-Window ist nach wie vor frei kopierbar, einzige Bedingung ist, daž
alle Dateien (MAUSWIND.ACC, MWLIGHT.ACC, MAUSWIND.GER und MAUSWIND.ENG)
komplett und unver„ndert weitergegeben werden (Archivierung ist
erlaubt).
Die Verbreitung in Mailboxen etc. ist nicht nur erlaubt, sondern
ausdrcklich erwnscht!
WICHTIG: Die Benutzung von Maus-Window erfolgt auf eigene Gefahr! Ich
bernehme keine Verantwortung fr Sch„den, die durch die sach- oder
unsachgem„že Anwendung von Maus-Window entstanden sind.
7. Planungen fr die Zukunft
----------------------------
Unter MultiTOS erh„lt bisher nur der MiniWin-Prozež h”here Priorit„t,
nicht auch das darin laufende TOS-Programm. Das wird hoffentlich
demn„chst besser werden (auch wenn ich mich dazu durch /proc
durchschlagen muž...)
Tja, im Moment f„llt mir leider nicht mehr ein... Falls jedoch jemand
noch eine zndende Idee hat, sollte er mir schreiben (Adresse(n) unter
Punkt 5), ich bin fr jeden brauchbaren Vorschlag dankbar...
8. Danksagungen und Grže
-------------------------
Tja, daran fhrt anscheindend kein Weg vorbei ;)
Ich danke
- dirch (Dirk Klemmt) fr seine POVShell, den Grundstein fr die Idee
zu TOS2GEM, Vorschl„ge, Bugreports, Aufmunterungen und die (teils
sinnlosen ;) Gespr„che per IRC
- rosebud (Uwe Seimet) fr den Diskus, die Hilfe bei meinen
Festplattenproblemen, sein Betatesting samt Vorschl„gen und die IRC-
Gespr„che
- moriati (Hidir Aras) fr's Betatesten und die IRC-"Sessions". (Der
Name stimmt jetzt offentlich, sorry nochmal!)
- d_gently (Marcus Haebler) fr seinen Fileselector fr MiNT (er wird
von Mal zu Mal besser!)
- chanel (Claus Brod) fr seinen Musikgeschmack ;) und seine
Hilfsbereitschaft
- AvAF30 (Arwin van Arum) fr die guten 8-Channel-Mods
- Equinoxe (Harald Sch”nfeld) fr die "Fachgespr„che" im IRC (ob wir
jemals den Schoner zusammenkriegen?)
- jackintos (Ewald Seibert) und dem Rest der Acher & Eberl & Seibert
GbR fr BlowUP030
- _tfs_ (Thomas Schulze) fr etliche MiNT-Utilities und fr's Betatesten
- Stfb (Stephane Boyeau) fr's Betatesten
- X (Roland Schorr) fr Betatests, Hilfe und Besorgungen ;)
- ki (Karsten Isakovic) fr's Betatesten und den SysMon
- RamaLama (Thorsten Schnurawa) fr's Nachschlagen in der MagiC-
Anleitung (jaja, ich weiž, da steht noch Mag!X drauf :-P )
- Eric Smith fr MiNT und die Antworten auf meine Fragen
- Michel Forget fr MasterBrowse, die Korrektur des englischen
Anleitungstextes und seine Vorschl„ge
- meinen MagiC-Betatestern Frank Bartels, Konrad Blum, Thomas Cloer,
Dietmar Konermann und Arno Welzel
- Arno Welzel nochmal speziell fr seinen Desktop "Thing", der wohl
auch bald TOS2GEM untersttzen wird
- Andreas Kromke fr seine Hilfe in Sachen MagiC
- ATARI fr den Falcon
- und noch einigen mehr, aber das wird dann wohl gar keinen mehr
interessieren...
Grže an
- dirch, rosebud, Equinoxe, d_gently, AvAF30, Apollo, moriati, chanel,
jackintos, connect, MrSpock, Griff, Infinity, Spoil, julian, thorson,
puujalka, kay_, _tfs_, TheFate, X, _uk_, daryl_, gsch, Stfb,
Stealth_, Riker, Rhemie, Crac, MickMouse, Scrap, RamaLama, Steinpilz,
NewMode, Anzaine, Mr_XY, LoST, Carnera, the-apple, ero und alle
anderen vom #atari-Channel, die ich vergessen habe
- DuffyDuck, swigert, mart, Hanni, HarryB und cbv, auch wenn sie das
wahrscheinlich nie lesen werden...
- alle, die ich noch vergessen habe
9. Žnderungen gegenber „lteren Versionen
-----------------------------------------
Žnderungen gegenber V1.32ž:
- Das Umschalten der Menleiste unter MagiC klappt jetzt wieder (ein
sehr peinlicher Fehler: Ich hatte appl_find("SCREENMGR") statt
appl_find("SCRENMGR") geschrieben, muž wohl irgendwie im Suff
passiert sein...)
- "Fensterlose Programme schtzen" funktioniert jetzt auch mit der
Systemshell von MagiC korrekt (bislang wurde es nicht richtig
erkannt, wenn sie keine Fenster offen hatte).
- Benutzung der rechten Maustaste zur Bedienung hinten liegender
Dialogfenster von Maus-Window sollte jetzt (wieder) richtig klappen
(ich hatte vergessen, die Maus zu reservieren).
- Es konnte passieren, daž die Fensterdialoge an eine "illegale"
Position gesnappt wurden, was zur Folge hatte, daž der Inhalt des
Fensters beim n„chsten Redraw versetzt gezeichnet wurde. Ist jetzt
behoben.
Žnderungen gegenber V1.31:
- Maus-Window pažt jetzt die Gr”že der USERDEF-Texte richtig an die des
Systemfonts an (da diese ja unter AES 4.1 beliebig ver„ndert werden
kann). Eine Anpassung an einen anderen Systemfont gibt es noch nicht,
weil es dabei zu Problemen kommt, wenn dieser proportional ist.
- Maus-Window verweigert die Arbeit, wenn mit dem aktiven Systemfont
nicht mindestens 40 x 23 Zeichen im Arbeitsbereich des Desktops
darstellbar sind.
- Es wird jetzt auch dann richtig geclippt, wenn ein USERDEF-Objekt
teilweise aužerhalb des Bildschirms liegt.
- Die Gr”že des Programmcodes konnte durch Verzicht auf die sprintf-
Funktion um ca. 1500 Bytes verringert werden.
Žnderungen gegenber V1.31ž:
- Erste Anpassungen an Geneva. Dabei hat sich leider gezeigt, daž die
Geneva-AES noch einige Probleme machen, vielleicht bessert sich das
ja noch...
- Bei Benutzung der Option "Priorit„t fr oberstes Fenster" unter
MultiTOS wird die Priorit„t jetzt um 40 erh”ht.
Žnderungen gegenber V1.30ž:
- Neue Option "Fensterlose Prog. schtzen" (Danke fr den Vorschlag,
Uwe!), die in einer Multitasking-Umgebung dafr sorgt, daž Programme
ohne eigene Fenster nicht durch ein Toppen "unerreichbar" werden.
- Wegen der neuen Option k”nnen die alten .INF-Files nicht mehr
benutzt werden, bitte neu anlegen!
- Unter MagiC sollte es jetzt nicht mehr vorkommen, daž Fenster von
Accessories und Programmen ohne Menleiste nach dem Toppen gleich
wieder inaktiv werden.
- Wenn nur das Info-Fenster offen ist, wird bei Anwahl des Accessory-
Eintrags das Parameterfenster ge”ffnet (bisher mužte man dazu erst
das Info-Fenster schliežen)
- Unter MultiTOS wurde bei aktivierter Option "Priorit„t fr oberstes
Fenster", wenn kein Fenster aktiv war dem Screenmanager h”here
Priorit„t gegeben. Das passiert jetzt nicht mehr.
- Wegen eines Fehlers in den MiNTLibs wurde die Priorit„t von Prozessen
nicht erh”ht, wenn ihre aktuelle Priorit„t kleiner Null war (Prenice
liefert normalerweise einen Long, die MiNTLibs haben aber Int als
Ergebnistyp eingetragen).
- Unter MultiTOS sollte es jetzt nicht mehr vorkommen, daž Fenster
nicht getoppt werden, obwohl dies nach Lage der Dinge der Fall sein
sollte.
Žnderungen gegenber V1.29:
- Folgende Probleme mit MagiC behoben (das lag an MagiC, *nicht* an
Maus-Window selbst!):
Wind_get-Aufruf zum Ermitteln des obersten Fensters angepažt (dadurch
funktioniert die Option "Verschwinden verhindern" vollst„ndig und es
wird auch dann getoppt, wenn es gerade kein aktives oberstes Fenster
gibt)
Beim Toppen eines Fensters wird jetzt auch dessen Menleiste
aktiviert, indem dem Screenmanager eine entsprechende Mitteilung
geschickt wird.
Eine kleine Anmerkung hierzu: Ich finde es h”chst seltsam, daž MagiC
in einigen Punkten so stark Rcksicht auf „ltere Programme nimmt, daž
sauber programmierte Applikationen nicht richtig laufen. Da hat man
doch irgendwie den Teufel mit dem Beelzebub ausgetrieben...
- Der Maus-Window-Objektbaum wird jetzt etwas schneller gezeichnet
(drfte haupts„chlich ohne NVDI auffallen...)
- Der Rahmen der Fensterdialoge wurde ganz entfernt (spart pro
Richtung satte 2 Pixel ;)
- Maus-Window versucht nun nicht mehr, bei der AC_CLOSED-Meldung die
Fenster per wind_delete zu entfernen (meine Dokumentation war fr
diesen Fall leider nicht eindeutig).
Žnderungen gegenber V1.29ž:
- Der wind_get-Fehler sollte jetzt entgltig gebannt sein (herzlichen
Dank an Dirk, der mich mit seinem "Alarm-Anruf" endlich auf die
richtige Spur gebracht hat...)
- Einige "kosmetische" Verbesserungen...
Žnderungen gegenber V1.28ž:
- Gelegentlich trat ein Fehler bei einem wind_get-Aufruf statt (er
machte sich bei Benutzung von WINX bemerkbar). Dies sollte jetzt
nicht mehr vorkommen.
- Die Option "Wartezeit" ist nun keine Alternative zu "nicht w„hrend
der Bewegung toppen" mehr, sondern kann auch zus„tzlich benutzt
werden. Das heižt, sind beide Optionen aktiviert, wird ein Fenster
erst dann getoppt, wenn die Maus die vorgegebene Zeit darber
stillgestanden hat.
Žnderungen gegenber V1.27ž:
- Maus-Window hat im Programmbetrieb jetzt eine eigene Menleiste.
Somit macht es mehr (oder erst richtig ;) Sinn, Maus-Window als
Programm zu starten, da a) das Parameterfenster nicht mehr sofort
ge”ffnet wird und man es b) somit auch nicht mehr offen lassen muž.
- Im Betrieb als Programm unter MultiTOS reagiert Maus-Window jetzt auf
die Nachricht AP_TERM und tr„gt sich "sch”ner" in die Menleiste ein.
Žnderungen gegenber V1.26:
- Neue Option "Wartezeit", als Alternative zu "nicht w„hrend Bewegung
toppen". Ist sie aktiviert, wird ein Fenster erst nach einer
einstellbaren Zeit (in 10tel Sekunden) getoppt.
- Durch die neue Option muž die Datei MAUSWIND.INF neu gesichert
werden, da sich das Format wieder ge„ndert hat (dies gilt eigentlich
generell, wenn eine Option dazugekommen ist).
- Compiliert mit MiNTLibs PL 44 (vorher 42)
- Das Info-Fenster erscheint jetzt parallel zum Parameterfenster
- S„mtliche graf_mkstate-Aufrufe durch eigene Routinen ersetzt, die
intern mit evnt_multi arbeiten. Dies sollte einige noch auftretende
Probleme (insbesondere mit MagiC) beheben. Mal sehen...
Žnderungen gegenber V1.25:
- Maus-Window wurde jetzt auf die MiNTLibs umgestellt, was leider auch
etwas gr”žere Executables zur Folge hatte. Es hat sich gezeigt, daž
die MiNTLibs bei Accessories nicht auf die MiNT-Domain umschalten,
sodaž die ebenfalls verbesserte Pfadbehandlung nur im Programm-Modus
zum Zuge kommt.
Žnderungen gegenber V1.24ž:
- Die Option "Priorit„t fr oberstes Fenster" versucht jetzt nicht
mehr, "h”chste" Priorit„t zu erreichen. Stattdessen wird die
Priorit„t um 20 erh”ht und sp„ter wieder auf den alten Wert
heruntergesetzt.
- "Priorit„t fr oberstes Fenster" ist nur noch w„hlbar, wenn Maus-
Window Root-Rechte hat (sollte unter "normalen" MultiTOS immer so
sein).
Žnderungen gegenber V1.23ž:
- Die Option "nur im Arbeitsbereich" funktionierte nur dann
vollst„ndig, wenn die betreffenden Fenster vollst„ndig sichtbar
waren. Dies ist jetzt behoben.
Žnderungen gegenber V1.22ž:
- Die Fenster von Maus-Window sind jetzt richtig unmodal, sie haben
einen Closer bekommen (war doch nicht so wild, Dirk...)
- Die Fensterdialoge werden jetzt nicht mehr "outlined" gezeichnet, das
spart etwas Platz und wird eigentlich fast immer so gemacht
Žnderungen gegenber V1.21ž:
- Einfhrung der neuen Option "erst nach Mausbewegung toppen", die
z.B. nach Fensterwechsel per Tastatur dafr sorgt, daž erst dann
wieder ein Fenster getoppt wird, wenn die Maus bewegt wurde
- Das Hauptdialogfenster ist rausgeflogen, dafr erscheint jetzt gleich
das Parameterfenster, vom dem aus auch das Infofenster erreicht
werden kann (na, jetzt zufrieden, Dirk?)
- angekreuzte und nicht anw„hlbare Checkboxen werden jetzt richtig
gezeichnet (hoffentlich)
Žnderungen gegenber V1.20ž:
- Dummen Bug unter MultiTOS beseitigt, der zum Systemstillstand fhrte
- Neue Option "Priorit„t fr oberstes Fenster" fr MultiTOS
Žnderungen gegenber V1.17:
- Maus-Window ist jetzt bilingual, d.h. die Dialoge und dieser
Anleitungstext existieren in Deutsch und in Englisch. Bei Maus-Window
wird dies automatisch ermittelt, den Anleitungstext muž man sich
selbst in der geeigneten Sprache aussuchen...
- Fr KAOS/NVDI 1.x-Benutzer existiert jetzt die Option "nur Mausklick
simulieren", die das Problem beseitigen soll, daž der Mauszeiger beim
Versuch, ein Fenster zu toppen, an den linken Bildschirmrand springt.
Žnderungen gegenber V1.16:
- Das Backdrop von WINX und MultiTOS wird jetzt untersttzt (was
allerdings nur bedingt funktioniert, da Maus-Window aufgrund seines
Funktionsprinzips das nach hinten gelegte Fenster in der Regel gleich
wieder nach vorne holt, falls es erreichbar ist)
- Ist WINX >= 2.1 installiert, verwendet Maus-Window wie unter MultiTOS
zum Toppen der Fenster nicht mehr das Simulieren eines Mausklicks,
sondern das Versenden einer entsprechenden Nachricht an den
"Besitzer" des Fensters. Dadurch ist auch unter WINX ab Version 2.1
der Button "nur im Arbeitsbereich" nicht mehr n”tig.
Žnderungen gegenber V1.15:
- H„lt man beim Anw„hlen des Accessory-Eintrags eine der Sondertasten
(Control, Shift oder Alternate) oder die rechte Maustaste gedrckt,
erscheint sofort das Parameter-Dialogfenster. Control ist dabei
nicht sehr empfehlenswert, da MultiTOS auf diese Weise Accessorys
entfernt...
- Ab AES-Version 3.31 benutzt Maus-Window zum Toppen eines Fensters
nicht mehr das Simulieren eines Mausklicks per appl_tplay. Vielmehr
wird ermittelt, welcher Applikation das betreffende Fenster geh”rt
(WF_OWNER bei wind_get) und dieser dann per appl_write die Nachricht
geschickt, daž das Fenster nach oben gebracht werden soll. Das bringt
insbesondere unter MultiTOS den Vorteil, daž man nicht mehr "nur im
Arbeitsbereich" aktivieren muž.
- Einige Probleme mit TOS 1.02 beseitigt: es war ein wind_update-
Befehl zuviel, was zum Stillstand fhrte; aužerdem wurde der
Eintrag in die Menzeile zu sp„t vorgenommen, sodaž er erst
nach einem Programmstart vorhanden war.
- In der "light"-Version stimmte die Alertbox nicht (das war mir nicht
gleich aufgefallen, weil der Fehler mit Let 'em Fly! nicht auftrat)
Žnderungen gegenber V1.10:
- Das Dialogfenster wurde in drei Einzelfenster aufgesplittet:
Hauptfenster, Parameterfenster und Infofenster.
- Es wurden weitere Parameter eingefhrt (Verdeckung von Fenstern
verhindern, nur bei Stillstand des Mauszeigers toppen, Festlegung der
Sondertasten, die Maus-Window am Toppen hindern sollen).
- Einfhrung von Maus-Window "light", der Sparversion von Maus-Window
ohne Einstellm”glichkeiten, aber mit sehr viel geringerem
Speicherverbrauch.
- Neugestaltung der Anleitung (die mich trotzdem noch nicht so recht
berzeugt)
Žnderungen gegenber V1.02:
- Maus-Window wurde im Prinzip komplett neu geschrieben. Es hat jetzt
anstelle der Einstelldialogbox ein nicht-modales Dialogfenster,
dessen Buttons auch tastaturbedienbar sind.
- Maus-Window l„uft auch als Programm, was aber nur mit einem
Multitasking-Betriebssystem sinnvoll ist.
- Es l„žt sich konfigurieren, ob, wie in Version 1.02 eingefhrt, ein
Fenster nur dann nach vorne geholt wird, wenn sich der Mauszeiger in
dessen Arbeitsbereich befindet.
- Die Konfiguration von Maus-Window (an/aus sowie Bercksichtigung des
Arbeitsbereiches ja/nein) l„žt sich als Parameterdatei speichern, die
bei Programmstart gelesen wird.
Žnderungen gegenber V1.01:
- Maus-Window holt ein Fenster nur noch dann nach vorne, wenn sich
der Mauszeiger innerhalb des Arbeitsbereichs des Fensters befin-
det (sonst werden unter MultiTOS oder WINX u.U. die Fensterele-
mente bedient, anstatt daž das Fenster getopped wird).
Žnderungen gegenber V1.00:
- Maus-Window wartet etwas l„nger zwischen zwei Tests, ob das Fenster
unter der Maus getopped werden muž (somit hat man bessere Chancen,
schnell mit dem Mauszeiger ber ein Fenster zu fahren, ohne es nach
oben zu holen).
- Es gab (und gibt leider immer noch) Probleme mit den AES, die sich ab
und zu einen Spaž erlauben und Maus-Window keine Timer-Events mehr
liefern. Dies fhrt dazu, daž Maus-Window nicht mehr arbeiten kann
(Abhilfe: Den Accessory-Eintrag anw„hlen und den Dialog mit OK
best„tigen, danach klappt wieder alles). Woran dies liegt, konnte ich
bis heute nicht feststellen (sehr wahrscheinlich an einem Fehler in
den AES, zumal es unter MultiTOS keine Schwierigkeiten gibt), auf
jeden Fall treten diese Probleme jetzt nicht mehr ganz so h„ufig auf.
Viel Spaž mit Maus-Window!