Maus-Window

Search
Votes / Statistics
Rating 
N/A
Hits: 2,360
Downloads: 581
Votes: 0
Your vote:
My Atarimania
Bookmark and Share
Comments (0)

Screenshots - Maus-Window

Maus-Window atari screenshot
Maus-Window atari screenshot
Maus-Window atari screenshot

Information - Maus-Window

GenreDOS / OSYear1994
LanguageCompiled CPublisher[no publisher]
Developer?DistributorAtari World
ControlsMouseCountryGermany
Box / InstructionsEnglish, GermanSoftwareEnglish
Programmer(s)

Binder, Thomas

LicensePD / Freeware / Shareware
SerialST TypeST, STe, TT / 0.5MB
ResolutionLow / Medium / HighNumber of Disks1 / Double-Sided
Dumpdownload atari Maus-Window Download / STMIDI
Protection

Instructions - Maus-Window

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 wnschenswert. 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 fr 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 fr 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 "Eigentmers" des betreffenden 
    Fensters und schickt diesem dann die Meldung, daž das Fenster getoppt 
    werden soll.

    Unter MultiTOS sorgt Maus-Window auf Wunsch auch dafr, daž der Prozež 
    mit dem obersten Fenster eine h”here Priorit„t erh„lt, was etwas 
    flssigeres 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 gewnschte Systemsprache im nicht-
    flchtigen RAM einstellen). Dies hat gegenber einer entsprechenden 
    Option fr 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 Menpunkts "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 entgltigen š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 
    dafr, wenn man unter WINX >= 2.1 oder MultiTOS problemlos die 
    Fensterelemente hinten liegender Fenster erreichen will (ohne muss man 
    schon etwas Glck 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 wrden (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 dafr, 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, wrde Maus-Window bei der n„chsten Gelegenheit 
    wieder Fenster 1 toppen, was ja eigentlich nicht unbedingt erwnscht 
    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 
    dafr, daž man auch das erreicht, was man wollte... Es ist zweckm„žig, 
    zus„tzlich "Nicht w„hrend Bewegung toppen" zu aktivieren.

    "Fensterlose Prog. schtzen"
    Unter Multitasking-Umgebungen kann ein Fensterwechsel auch einen 
    Applikationswechsel zur Folge haben, wobei auch die Menleiste 
    umgeschaltet wird. Mit der Option "Fensterlose Prog. schtzen" kann nun 
    dafr gesorgt werden, daž Maus-Window nicht toppt, wenn die 
    Applikation, deren Menleiste gerade aktiv ist, keine Fenster offen 
    hat. Der Sinn liegt darin, daž sonst ja die Menleiste des Programms 
    weg w„re und man mangels Fenster nur noch durch Umschalten der 
    Applikation an das Programm k„me. Wenn die AES es untersttzen, prft 
    Maus-Window zus„tzlich, ob das zu toppende Fenster einem Accessory 
    geh”rt, wenn ja, wird es doch getoppt, da ein Accessory keine eigene 
    Menleiste hat. Es ist leider nicht m”glich, auch zu prfen, ob das 
    Programm, dem das zu toppende Fenster geh”rt, berhaupt eine Menleiste 
    besitzt; daher k”nnen nur Accessories bercksichtigt werden. 
    "Fensterlose Prog. schtzen" ist nur w„hlbar, wenn die AES mehr als 
    eine Applikation erlauben (Multitasking) und den erweiterten menu_bar-
    Aufruf bereitstellen. Das Bercksichtigen der Acceossry-Fenster ist nur 
    m”glich, wenn die AES den appl_search-Aufruf untersttzen. Beides ist 
    bei MultiTOS, MagiC und Geneva der Fall.

    "Priorit„t fr oberstes Fenster":
    Diese Option ist nur w„hlbar, wenn unter MultiTOS gearbeitet wird (fr 
    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 zurckgesetzt, 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 gedrckt ist (gedrckte 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 krzer (nur ca. 18 Prozent der 
    Normalversion), bietet keine Online-Einstellungsm”glichkeit und l„uft 
    nur als Accessory.

    Maus-Window "light" bercksichtigt 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 fr 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 fhrt, daž 
    der Quelltext verloren ist. Mit Pure C 1.1 drfte 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 fhre dann eine entsprechende Liste, die ich jedem zuschicke, der 
    mir einen an sich selbst adressierten, frankierten Rckumschlag 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 ungnstigsten 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 erwnscht 
    sein drfte. 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 fhrt, 
    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 Mens: es wird manchmal kein wind_update(BEG_UPDATE) 
    aufgerufen, was u.a. dazu fhrt, daž Maus-Window bei ausgeklappten 
    Mens 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-Mens: 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 
    gnstigsten Fall wird sie entweder einfach ignoriert (sauberes 
    Programm) oder das Fenster trotzdem getoppt, im schlechtesten strzt 
    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 wrde mich aužerdem 
    zus„tzlich anspornen, Maus-Window zu DEM Auto-Window-Topper fr 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 
    ausdrcklich erwnscht!

    WICHTIG: Die Benutzung von Maus-Window erfolgt auf eigene Gefahr! Ich 
    bernehme keine Verantwortung fr Sch„den, die durch die sach- oder 
    unsachgem„že Anwendung von Maus-Window entstanden sind.


    7. Planungen fr 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 zndende Idee hat, sollte er mir schreiben (Adresse(n) unter 
    Punkt 5), ich bin fr jeden brauchbaren Vorschlag dankbar...


    8. Danksagungen und Grže
    -------------------------

    Tja, daran fhrt anscheindend kein Weg vorbei ;)

    Ich danke
    - dirch (Dirk Klemmt) fr seine POVShell, den Grundstein fr die Idee 
      zu TOS2GEM, Vorschl„ge, Bugreports, Aufmunterungen und die (teils 
      sinnlosen ;) Gespr„che per IRC
    - rosebud (Uwe Seimet) fr den Diskus, die Hilfe bei meinen 
      Festplattenproblemen, sein Betatesting samt Vorschl„gen und die IRC-
      Gespr„che
    - moriati (Hidir Aras) fr's Betatesten und die IRC-"Sessions". (Der 
      Name stimmt jetzt offentlich, sorry nochmal!)
    - d_gently (Marcus Haebler) fr seinen Fileselector fr MiNT (er wird 
      von Mal zu Mal besser!)
    - chanel (Claus Brod) fr seinen Musikgeschmack ;) und seine 
      Hilfsbereitschaft
    - AvAF30 (Arwin van Arum) fr die guten 8-Channel-Mods
    - Equinoxe (Harald Sch”nfeld) fr die "Fachgespr„che" im IRC (ob wir 
      jemals den Schoner zusammenkriegen?)
    - jackintos (Ewald Seibert) und dem Rest der Acher & Eberl & Seibert 
      GbR fr BlowUP030
    - _tfs_ (Thomas Schulze) fr etliche MiNT-Utilities und fr's Betatesten
    - Stfb (Stephane Boyeau) fr's Betatesten
    - X (Roland Schorr) fr Betatests, Hilfe und Besorgungen ;)
    - ki (Karsten Isakovic) fr's Betatesten und den SysMon
    - RamaLama (Thorsten Schnurawa) fr's Nachschlagen in der MagiC-
      Anleitung (jaja, ich weiž, da steht noch Mag!X drauf :-P )
    - Eric Smith fr MiNT und die Antworten auf meine Fragen
    - Michel Forget fr 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 fr seinen Desktop "Thing", der wohl 
      auch bald TOS2GEM untersttzen wird
    - Andreas Kromke fr seine Hilfe in Sachen MagiC
    - ATARI fr 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 gegenber „lteren Versionen
    -----------------------------------------

    Žnderungen gegenber V1.32ž:
    - Das Umschalten der Menleiste 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 schtzen" 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 gegenber 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 gegenber 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 fr oberstes Fenster" unter 
      MultiTOS wird die Priorit„t jetzt um 40 erh”ht.

    Žnderungen gegenber V1.30ž:
    - Neue Option "Fensterlose Prog. schtzen" (Danke fr den Vorschlag, 
      Uwe!), die in einer Multitasking-Umgebung dafr 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 Menleiste 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 fr 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 gegenber 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 Menleiste 
      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 Rcksicht 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 
      (drfte 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 fr 
      diesen Fall leider nicht eindeutig).

    Žnderungen gegenber V1.29ž:
    - Der wind_get-Fehler sollte jetzt entgltig gebannt sein (herzlichen 
      Dank an Dirk, der mich mit seinem "Alarm-Anruf" endlich auf die 
      richtige Spur gebracht hat...)
    - Einige "kosmetische" Verbesserungen...

    Žnderungen gegenber 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 darber 
      stillgestanden hat.

    Žnderungen gegenber V1.27ž:
    - Maus-Window hat im Programmbetrieb jetzt eine eigene Menleiste. 
      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 Menleiste ein.

    Žnderungen gegenber 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 gegenber 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 gegenber V1.24ž:
    - Die Option "Priorit„t fr 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 fr oberstes Fenster" ist nur noch w„hlbar, wenn Maus-
      Window Root-Rechte hat (sollte unter "normalen" MultiTOS immer so 
      sein).

    Žnderungen gegenber 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 gegenber 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 gegenber V1.21ž:
    - Einfhrung der neuen Option "erst nach Mausbewegung toppen", die 
      z.B. nach Fensterwechsel per Tastatur dafr sorgt, daž erst dann 
      wieder ein Fenster getoppt wird, wenn die Maus bewegt wurde
    - Das Hauptdialogfenster ist rausgeflogen, dafr 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 gegenber V1.20ž:
    - Dummen Bug unter MultiTOS beseitigt, der zum Systemstillstand fhrte
    - Neue Option "Priorit„t fr oberstes Fenster" fr MultiTOS

    Žnderungen gegenber 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...
    - Fr 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 gegenber V1.16:
    - Das Backdrop von WINX und MultiTOS wird jetzt untersttzt (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 gegenber V1.15:
    - H„lt man beim Anw„hlen des Accessory-Eintrags eine der Sondertasten 
      (Control, Shift oder Alternate) oder die rechte Maustaste gedrckt, 
      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 fhrte; aužerdem wurde der 
      Eintrag in die Menzeile 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 gegenber V1.10:
    - Das Dialogfenster wurde in drei Einzelfenster aufgesplittet: 
      Hauptfenster, Parameterfenster und Infofenster.
    - Es wurden weitere Parameter eingefhrt (Verdeckung von Fenstern 
      verhindern, nur bei Stillstand des Mauszeigers toppen, Festlegung der 
      Sondertasten, die Maus-Window am Toppen hindern sollen).
    - Einfhrung 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 gegenber 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 eingefhrt, ein 
      Fenster nur dann nach vorne geholt wird, wenn sich der Mauszeiger in 
      dessen Arbeitsbereich befindet.
    - Die Konfiguration von Maus-Window (an/aus sowie Bercksichtigung des 
      Arbeitsbereiches ja/nein) l„žt sich als Parameterdatei speichern, die 
      bei Programmstart gelesen wird.

    Žnderungen gegenber 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 gegenber 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 fhrt 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!

Book / Magazine Reviews - Maus-Window

 Atari World · June, 1995Rating: 6 Worlds 

Maus-Window Atari review 

About Us - Contact - Credits - Powered with Webdev - © Atarimania 2003-2019