home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / AT_WORLD / ATRIW2A.MSA / MAUSWIND.A62_MAUSWIND.ENG < prev    next >
Text File  |  1994-10-31  |  31KB  |  592 lines
  1.     Manual For Maus-Window V1.32 (as of 11/01/94)
  2.     ---------------------------------------------
  3.  
  4.  
  5.     1. Maus-Window?
  6.     ---------------
  7.  
  8.     People who have worked with X11 will have noticed that the active 
  9.     window is always the window located under the mouse-cursor (unless the 
  10.     window-manager has been configured otherwise). A similar behavior for 
  11.     ATARI-GEM would be nice, but unfortunately this can only be achieved by 
  12.     topping the window (or rewriting parts of the operating system). I 
  13.     found an article addressing this problem in a german magazine, but the 
  14.     methods described in there to automatically top a window all had 
  15.     serious disadvantages. So I decided to write a program to top windows 
  16.     myself, and the result is this accessory called Maus-Window. To install 
  17.     it, copy it to the root directory of the boot-drive. Maus-Window can 
  18.     also be used as a program, but this only makes sense in a multitasking-
  19.     environment. Maus-Window has no problems running under MultiTOS, 
  20.     MagiC, and Geneva, as an accessory or an application.
  21.  
  22.     When Maus-Window is active and the mouse-cursor resides over a non-
  23.     active window, the window will automatically be topped. This is 
  24.     achieved by simulating a mouse-click using the AES-call appl_tplay(). 
  25.     This confors to GEM and causes no problems with "clean" applications 
  26.     (see section 4 for a description of problematic programs).
  27.  
  28.     If the AES version number is >= 3.31, or if WINX >= 2.1 is installed, 
  29.     Maus-Window uses their extensions to find the owner of the affected 
  30.     window and then sends a WM_TOPPED-message to this application.
  31.  
  32.     When run under MultiTOS, Maus-Window additionally offers the 
  33.     possibility to raise the priority of the process with the topmost 
  34.     window. This allows more comfortable work.
  35.  
  36.     As of version 1.20, Maus-Window is bilingual, and thus has german and 
  37.     english dialogs. If the language of the computer running Maus-Window is 
  38.     not German, english dialogs will be used. If german dialogs are 
  39.     desired, install an _AKP-cookie (see: issue 4/93 German ST-Computer, 
  40.     Page 89) or (for MultiTOS users) set the AE_LANG environment variable. 
  41.     Falcon users can set the preferred language by using one of the NVRAM 
  42.     configuration utilities. This is the best method, since it will cause 
  43.     many other programs to show german text instead of english text as well.
  44.  
  45.  
  46.     2. Maus-Window Options
  47.     ----------------------
  48.  
  49.     When Maus-Window is activated (by selecting the entry in the desk-
  50.     menu), it shows a dialog in a window. In the parameter-box some options 
  51.     may be set (and later saved) which affect the behaviour of Maus-Window. 
  52.     Any changes made here will immediatly take effect. The "OK"-Buttons is 
  53.     only used for finally accepting the new settings (similar to XCONTROL-
  54.     modules). When Maus-Window is run as a program, you get this dialog by 
  55.     selecting the entry "Options: edit..." in the menu-bar.
  56.  
  57.     Maus-Window offers the following options:
  58.  
  59.     "Maus-Window active":
  60.     Tells Maus-Window whether it should top windows or not.
  61.  
  62.     "work-area only":
  63.     If this checkbox is crossed, windows will only be topped if the mouse-
  64.     cursor is located in the work-area of a window. With WINX < 2.1, this 
  65.     option must be selected (since not having done so might cause window 
  66.     gadgets to be operated instead of topping the window). This option is 
  67.     also useful for WINX >= 2.1 or MultiTOS, because then it's easier to 
  68.     operate the gadgets of background windows (otherwise, it may come to 
  69.     pass that the affected window is topped before).
  70.  
  71.     "prevent 'disappearing'":
  72.     Tells Maus-Window whether it should not top a window if it would 
  73.     completely cover the topmost window (or it's work-area, depeding on the 
  74.     setting of "work-area only").
  75.  
  76.     "don't top during mouse-movement":
  77.     If you do not want Maus-Window to top windows while the mouse is being 
  78.     moved, you should select this option.
  79.  
  80.     "delay: ..."
  81.     This option will cause Maus-Window to wait a certain amount of time 
  82.     until it tops a window (that means, the mouse-cursor must have been 
  83.     over the window for that time). The duration of the delay is measured 
  84.     in ds (10th parts of a second) and can be selected by using the up and 
  85.     down arrow (either the arrows in the dialog or the cursor-keys). Use 
  86.     double-clicks to increase/ decrease the value by ten.
  87.  
  88.     "wait for mouse-movement":
  89.     If this option is activated, Maus-Window will wait for a mouse-movement 
  90.     after the last change of the top-window. Example: Two windows are open, 
  91.     the mouse-cursor is in window #1, which is the topmost window. Now 
  92.     window #2 is topped through a keyboard action (like cycling windows). 
  93.     Without this option, Maus-Window will immediatly top window #1 again 
  94.     (which was obviously not the intention of the user). With this option 
  95.     active, Maus-Window will wait until the mouse is moved again, so window 
  96.     #2 will stay "on top". This option is also useful when using the 
  97.     backdrop-feature of MultiTOS or WINX. It is a good idea to also 
  98.     activate the option "don't top during mouse-movement".
  99.  
  100.     "protect windowless applications":
  101.     When working in a multitasking-environment, changing the active window 
  102.     may also mean changing the active application and the menu-bar. Since 
  103.     it is possible that an active application has no window open (then 
  104.     there is no active window), changing to another application by topping 
  105.     one if its windows causes the program without windows to be "lost". 
  106.     That means, it can't be reactivated by clicking on a window. If you 
  107.     don't want this, use this option. It causes Maus-Window to check if the 
  108.     active application has one or more windows open before topping one of 
  109.     another program. If the AES support it, Maus-Window will also check if 
  110.     the window which is going to be topped belongs to an accessory. In that 
  111.     case, that window will be activated even when the active application 
  112.     has no own windows, since accessories don't have menu-bars and thus 
  113.     activating a window of an accessory doesn't affect the active menu. It 
  114.     is not possible to check whether an application has an own menu-bar or 
  115.     not, so this extra-feature only affects accessories. "Protect 
  116.     windowless applications" is only available if the AES allow more than 
  117.     one application (multitasking) and support the extended menu_bar-call. 
  118.     The extra-feature (option doesn't affect windows of accessories) will 
  119.     be used if the AES have the appl_search-function. Both calls are 
  120.     supported by MultiTOS, MagiC and Geneva.
  121.  
  122.     "higher priority for top-window":
  123.     This option can only be used when running MultiTOS (Maus-Window also 
  124.     must have effective user ID 0, but this is only important for experts). 
  125.     If it is active, Maus-Window will automatically raise the priority of 
  126.     the process with the topmost window. The priority is reset to the old 
  127.     value if another process gets the top-window.
  128.  
  129.     "use mouse-click only":
  130.     As described in section 4, with KAOS and/or NVDI 1.x it may come to 
  131.     pass that the mouse-cursor jumps to the left border of the screen when 
  132.     Maus-Window tops a window. This options removes the problem by only 
  133.     simulating a mouse-click. Normally, the mouse-cursor is first 
  134.     postiioned in such a way that the simulated click really hits the 
  135.     correct window. It is a good idea to also select the option "don't top 
  136.     during mouse-movement", because otherwise it may come to pass that 
  137.     during fast mouse-movement the simulated click hits the wrong window. 
  138.     "Use mouse-click only" cannot be selected when working with WINX >= 2.1 
  139.     or AES >= 3.31, because in that case Maus-Window does not use a mouse-
  140.     click to top a window.
  141.  
  142.     Additionally, it is possible to decide which "special-keys" (shift 
  143.     left/right, control, and alternate) prevent Maus-Window from topping 
  144.     windows (though holding down the mouse-buttons will always have this 
  145.     effect).
  146.  
  147.     To have the current settings as default, it is possible to save them in 
  148.     a file called MAUSWIND.INF. It should be located in the same directory 
  149.     as the program/accessory itself (it is searched with shel_find). On 
  150.     startup, Maus-Window looks for this file and uses the settings saved in 
  151.     it. If the file does not exist, all options are activated.
  152.  
  153.     The button "OK" replaces the current settings and closes the dialog. 
  154.     "Cancel" recalls the last settings and then quits the dialog. "Info" 
  155.     calls a window with some short information about Maus-Window.
  156.  
  157.  
  158.     3. Maus-Window "light"
  159.     ----------------------
  160.  
  161.     Since it seems to be necessary to have a "light"-version of every 
  162.     product, I did the same with Maus-Window. Maus-Window "light" is much 
  163.     shorter (only about 18% of the the size of the normal version), and 
  164.     offers no online-settings. It can only be used as an accessory.
  165.  
  166.     Maus-Window "light" also uses the file MAUSWIND.INF, but can only be 
  167.     set on and off (using and alert box that is shown when the entry under 
  168.     the Desk menu is selected).
  169.  
  170.     Thus, Maus-Window "light" is good for all people who only want to set 
  171.     the options once and then use the less memory-consuming version.
  172.  
  173.  
  174.     4. Problematic Programs
  175.     -----------------------
  176.  
  177.     As mentioned above, Maus-Window fully conforms to the GEM-conventions. 
  178.     It is necessary that the running applications follow these rules, too, 
  179.     though. For example, Maus-Window won't be able to top windows in 
  180.     programs which do not use real GEM-windows (Example: early versions of 
  181.     CyPress) or do not react to the AES-messages correctly. Moreover, there 
  182.     are programs which rely on certain behaviours of GEM which are not 
  183.     documentated, which can also cause problems. Unfortunately, Pure C 1.0 
  184.     (it was used to develop Maus-Window) is one of them: When the help-
  185.     system is called by pressing the Help key, Pure C opens a window. It 
  186.     may be that the mouse-cursor resides over another Pure C window at that 
  187.     moment, in which case Maus-Window will top it. Pure C ignores that and 
  188.     writes the output of the help-system directly into the topmost window. 
  189.     Additionally, the internal window-structure of Pure C gets confused, 
  190.     ending up in a loss of the sourecode in the topmost window. Pure C 1.1 
  191.     shouldn't have this problem anymore, since the window-code has been 
  192.     improved. It is possible to avoid this problem by activating Maus-
  193.     Window's option "wait for mouse-movement".
  194.  
  195.     If you recognize more programs that cause problems with Maus-Window, 
  196.     you should contact me (see section 5 for my address). I'm going to keep 
  197.     a list of these programs, which I will send to everyone who sends an 
  198.     envelope with his/her address and enough postage on it to cover 
  199.     mailing, or anyone who is able to receive email. Authors of problematic 
  200.     programs should think about recoding the corresponding parts of their 
  201.     work, because it's quite likely that these programs will cause problems 
  202.     with multitasking-environments or WINX, too.
  203.  
  204.     There are also problems with applications that allow the use of 
  205.     windowed dialogs lying in the background without having AES >= 4.0 or 
  206.     WINX >= 2.1. In that case, Maus-Window won't be able to top these 
  207.     windows, but will, in the worst case, operate one of the buttons of the 
  208.     windowed dialog. There's no way to solve that problem, you can only 
  209.     avoid it by using one of the shift-keys to prevent Maus-Window from 
  210.     trying to top such windows. Actually, this problem is due to a fault of 
  211.     the programmers of such applications, since they do not interpret the 
  212.     message that a window should be topped properly.
  213.  
  214.     When you are using programs that allow background-window-operation by 
  215.     using the extended features of newer AES-versions (WF_EVENT), Maus-
  216.     Window will correctly top the windows, but you may sometimes find this 
  217.     annoying. In that case, you can also use one of the shift-keys to 
  218.     temporarily deactive Maus-Window.
  219.  
  220.     Some people told me that Maus-Window has problems with NVDI 1.x and/or 
  221.     KAOS-TOS. Instead of topping a window, the mouse-cursor only jumps to 
  222.     the left border of the screen. I really don't know why this happens, 
  223.     but I'm quite sure it's due to an error in the VDI-routines called by 
  224.     appl_tplay, because to make sure that the mouse-click hits the correct 
  225.     window, Maus-Window's appl_tplay-call also includes some mouse-
  226.     positioning (this is legal!). To avoid this problems, I've included the 
  227.     option "use mouse-click only"; I can't tell if this really works 
  228.     (because I can't test it myself), but I'm quite sure it does. Another 
  229.     way to avoid this problem is using MultiTOS or WINX >= 2.1, because 
  230.     Maus-Window will then use a different method to top a window.
  231.  
  232.     Older versions of Mag!X 2.0 seem to have a problem with drawing drop-
  233.     down-menus: Sometimes no wind_update(BEG_UPDATE) is called, so Maus-
  234.     Window tops windows while a menu is active. Easy to imagine how this 
  235.     looks like... The new Mag!X (> 2.0, now called MagiC) shouldn't have 
  236.     this problem any longer. Some of my beta-testers also reported that it 
  237.     is impossible to run Maus-Window from within the \AUTO\APPS-folder. The 
  238.     strange thing is that this didn't happen to all of the MagiC-users. 
  239.     That also means that I can't make any reliable comments on this, so you 
  240.     have to try and see if it works...
  241.  
  242.     Geneva's "Tear-Away-Menu"-windows also cause problems: According to 
  243.     wind_get, they belong to the application they were torn off, but since 
  244.     the application doesn't know anything about the existence of these 
  245.     windows, it won't react to Maus-Window's WM_TOPPED-message correctly. 
  246.     The best what may happen is that the message is ignored (correct 
  247.     reaction) or the window's topped although it hasn't been opened by the 
  248.     application itself. The worst case is that the program hangs up, for 
  249.     example because it can't find the window in its internal window-list. 
  250.     Up to now, I've no idea how to solve this problem, maybe one of the 
  251.     Geneva-users out there has an idea?
  252.  
  253.  
  254.     5. Contacting The Author
  255.     ------------------------
  256.  
  257.     Everyone who wants to get the list of problematic programs or wants to 
  258.     make suggestions/bugreports should write to this address:
  259.  
  260.     Thomas Binder
  261.     Johann-Valentin-May-Straße 7
  262.     64665 Alsbach-Hähnlein
  263.     Germany
  264.  
  265.     InterNet: binder@rbg.informatik.th-darmstadt.de
  266.     IRC: Gryf
  267.  
  268.     If you think Maus-Window is worth a donnation, use this bank account 
  269.     (if you are able to transfer money to Germany from where you live):
  270.  
  271.     Dresdner Bank AG Frankfurt/Main
  272.     Account-Nr. 9 024 050 00
  273.     BLZ 500 800 00 (I don't know if there is an equivilant to 'BLZ' in the
  274.                    english language)
  275.  
  276.     To be precise: I've already put a lot of work into Maus-Window, but I 
  277.     want to keep it being freely distributable. So it would be very nice if 
  278.     everyone who uses Maus-Window regularly would send a little donnation. 
  279.     This would also encourage me in making Maus-Window THE auto-window-
  280.     topper for the ATARI.
  281.  
  282.  
  283.     6. How To Copy Maus-Window
  284.     --------------------------
  285.  
  286.     Maus-Window may still be freely distributed. The only condition is that 
  287.     all files (MAUSWIND.ACC, MWLIGHT.ACC, MAUSWIND.GER and MAUSWIND.ENG) 
  288.     are copied completely and unchanged (archiving is allowed).
  289.  
  290.     Spreading Maus-Window to bbs'es etc. is not only allowed, it's strongly 
  291.     encouraged!
  292.  
  293.     IMPORTANT: Use Maus-Window at your own risk! I do not undertake any 
  294.     responsibility for damages which occur after the correct or incorrect 
  295.     use of Maus-Window.
  296.  
  297.  
  298.     7. Plans For Future Versions
  299.     ----------------------------
  300.  
  301.     Up to now, only the priority of the MiniWin-process itself is raised, 
  302.     not the priority of the corresponding TOS-program. I hope to improve 
  303.     that soon (even when I have to work through /proc to do so...)
  304.  
  305.     That's all for the moment, maybe you have a good idea what I could 
  306.     improve. If so, please contact me (see section 5 for my address), I'll 
  307.     appreciate all useful suggestions...
  308.  
  309.  
  310.     8. Thanks & Greetings
  311.     ---------------------
  312.  
  313.     Oh well, it seems I can't avoid that ;)
  314.  
  315.     I thank
  316.     - dirch (Dirk Klemmt) for his POVShell, the basis for my idea of 
  317.       TOS2GEM, suggestions, bugreports, encouragements and the (sometimes 
  318.       senseless ;) IR-chats
  319.     - rosebud (Uwe Seimet) for betatesting, suggestions, Diskus, help with 
  320.       my HD-problems and the IR-chats
  321.     - moriati (Hider Aras) for betatesting and our IRC-"sessions" (hope I 
  322.       spelled the name correctly this time, sorry again for the typo!)
  323.     - d_gently (Marcus Haebler) for his fileselector for MiNT (it gets 
  324.       better and better!)
  325.     - chanel (Claus Brod) for his favourite music ;) and his help
  326.     - AvAF30 (Arwin van Arum) for the great 8-channel-mods
  327.     - Equinoxe (Harald Schönfeld) for the "professional" chats (do you 
  328.       think we'll ever make our screen-saver?)
  329.     - jackintos (Ewald Seibert) and the others of the Acher & Eberl & 
  330.       Seibert GbR for BlowUP030
  331.     - _tfs_ (Thomas Schulze) for several MiNT-utilities and for beta-testing
  332.     - Stfb (Stephane Boyeau) for beta-testing
  333.     - X (Roland Schorr) for beta-tests, help, and procurements ;)
  334.     - ki (Karsten Isakovic) for betatesting and his SysMon
  335.     - RamaLama (Thorsten Schnurawa) for looking up things in his MagiC-
  336.       manual (I know, it still says Mag!X on the cover :-P )
  337.     - Eric Smith for MiNT and answering my questions
  338.     - Michel Forget for MasterBrowse, correcting this text, and his 
  339.       suggestions
  340.     - My MagiC-betatesters Frank Bartels, Konrad Blum, Thomas Cloer, 
  341.       Dietmar Konermann, and Arno Welzel, ...
  342.     - Arno Welzel again for his desktop "Thing", that will maybe soon 
  343.       support TOS2GEM, too
  344.     - Andreas Kromke for his help on MagiC
  345.     - ATARI for the Falcon
  346.     - and some more, but I'm sure nobody will be interested in that...
  347.  
  348.     Greetings go to
  349.     - dirch, rosebud, Equinoxe, d_gently, AvAF30, Apollo, moriati, chanel, 
  350.       jackintos, connect, MrSpock, Griff, Infinity, Spoil, julian, thorson, 
  351.       puujalka, kay_, _tfs_, TheFate, X, _uk_, daryl_, gsch, Stfb, 
  352.       Stealth_, Riker, Rhemie, Crac, MickMouse, Scrap, RamaLama, Steinpilz, 
  353.       NewMode, Anzaine, Mr_XY, LoST, Carnera, the-apple, ero, and the rest 
  354.       of #atari I've forgotten
  355.     - DuffyDuck, swigert, mart, Hanni, HarryB and cbv, even though they 
  356.       sure won't ever read this...
  357.     - the rest I've forgotten
  358.  
  359.  
  360.     9. Changes To Older Versions
  361.     ----------------------------
  362.  
  363.     Changes since V1.32ß:
  364.     - Activating the menu-bar of an application when running MagiC now 
  365.       works again (a very embarrassing bug: I wrote appl_find("SCREENMGR") 
  366.       instead of appl_find("SCRENMGR"), maybe I was drunk when I did 
  367.       that...)
  368.     - "Protect windowless applications" should now also work with the 
  369.       system-shell of MagiC (up to now, Maus-Window didn't detect correctly 
  370.       if the shell didn't have any open windows).
  371.     - Using the right mouse-button to operate background-dialogs now works 
  372.       correctly (again) (I forgot to lock the mouse).
  373.     - Sometimes the windowed dialogs didn't snap to a correct position, so 
  374.       the contents was a bit misplaced after the next redraw. This is fixed 
  375.       now.
  376.  
  377.     Changes since V1.31:
  378.     - Maus-Window now correctly adjusts the USERDEF-text to the size of the 
  379.       system-font (because it's possible to change it with AES 4.1). A 
  380.       completely other system-font is not recognized yet, because there are 
  381.       some problems if it's a proportional font.
  382.     - Maus-Window will not work if it's not possible to display at least 
  383.       40x23 characters with the current system-font.
  384.     - Clipping of USERDEF-objects now also works correctly if parts of them 
  385.       are off-screen.
  386.     - The size of MAUSWIND.ACC has been reduced by about 1500 bytes, 
  387.       because I don't use the sprintf-function anymore.
  388.  
  389.     Changes since V1.31ß:
  390.     - Should now also work correctly with Geneva. It seems that the Geneva-
  391.       AES (still) have some problems you have to work around. Maybe this 
  392.       gets better one day...
  393.     - When using MultiTOS with the option "higher priority for top-window", 
  394.       the priority is now raised by 40.
  395.  
  396.  
  397.     Changes since V1.30ß:
  398.     - New option "protect windowless applications", which takes care that 
  399.       no programs without open windows "get lost" in a multitasking-
  400.       environment
  401.     - Due to the new option, the old .INF-files can't be used any longer, 
  402.       so you have to set and save your preferences again.
  403.     - When using MagiC, windows of accessories and programs without an own 
  404.       menu-bar were deactivated right after they were topped. This should 
  405.       be fixed now.
  406.     - When you only have the info-dialog open, selecting the accessory-
  407.       entry will bring up the parameter-window (up to now, you had to close 
  408.       the info-window first to do so)
  409.     - Under MultiTOS, the priority of the screen-manager was raised, when 
  410.       there was no active window and the option "higher priority for top-
  411.       window" was activated. This is fixed now.
  412.     - Due to an error in the MiNTLibs, Maus-Window didn't raise the 
  413.       priority of processes which had a current priority < 0 (the GEMDOS-
  414.       call Prenice usually returns a long, but the MiNTLibs declared it 
  415.       returning int).
  416.     - It now shouldn't happen anymore that windows sometimes don't get 
  417.       topped when using MultiTOS.
  418.  
  419.     Changes since V1.29:
  420.     - Fixed the following problems with MagiC (caused by MagiC, *not* by 
  421.       Maus-Window itself!):
  422.       Adjusted wind_get-call to get topmost window (this causes the option 
  423.       "prevent 'disappearing'" to work correctly and Maus-Window to top 
  424.       even if there is no active topmost window)
  425.       When a window is topped, now also the menu-bar of the affected 
  426.       application is activated. This is done by sending a special message 
  427.       to the screen-manager.
  428.       A short comment: I'm really astonished at the fact that MagiC causes 
  429.       "clean" applications to work improperly because it has so much 
  430.       regards for older (not "clean") programs. This is not what I 
  431.       understand as "compatibilty".
  432.     - Maus-Window's object-tree is now drawn a bit faster (mostly 
  433.       noticeable without NVDI...)
  434.     - The frame of the windowed dialogs has been removed (this saves 2 
  435.       pixels per direction ;)
  436.     - Maus-Window now doesn't try to call wind_delete upon receiving the 
  437.       AC_CLOSED-message anymore (my documentation wasn't very precise in 
  438.       that case).
  439.  
  440.     Changes since V1.29ß:
  441.     - The wind_get-call-error should now be really fixed
  442.     - Some "cosmetic" changes...
  443.  
  444.     Changes since V1.28ß:
  445.     - In sometimes happened that a wind_get-call failed (this was 
  446.       noticeable when using WINX). Should be removed now.
  447.     - The option "delay" no longer is an alternative to "don't top during 
  448.       mouse-movement", both may be selected at the same time. In that case, 
  449.       a window will only be topped after the mouse-cursor hasn't moved for 
  450.       the given time.
  451.  
  452.     Changes since V1.27ß:
  453.     - Maus-Window now has it's own menu-bar, when run as a program. So now 
  454.       it makes more sense to run it as a program (in a multitasking-
  455.       environment, of course), because you don't have to keep the windows 
  456.       open.
  457.     - When run as a program, Maus-Window now reacts to the AP_TERM-message 
  458.       and uses a real entry in the menu-bar (this is only important in 
  459.       connection with MultiTOS).
  460.  
  461.     Changes since V1.26:
  462.     - New option "delay", thought as an alternative to "don't top during 
  463.       mouse-movement". If this option is activated, a window won't be 
  464.       topped until a certain amount of time (measured in 10th parts of a 
  465.       second) has passed.
  466.     - Due to the new option, the format of the MAUSWIND.INF-file has 
  467.       changed, so you must set and save your preferences again (this always 
  468.       happens when new options are introduced, but I didn't mention that 
  469.       before).
  470.     - Now compiled with MiNTLibs PL 44 (V1.26 used PL 42)
  471.     - When the info-dialog is called, the parameter-window isn't closed any 
  472.       more (so both windows are on the screen at the same time)
  473.     - All calls to graf_mkstate have been replaced by own routines, which 
  474.       internally use evnt_multi. This should remove some problems 
  475.       (especially when using Mag!X). Let's see...
  476.  
  477.     Changes since V1.25:
  478.     - Maus-Window is now compiled using the MiNTLibs, unfortunately, this 
  479.       also leads to larger executables. The MiNTLibs do not set the MiNT-
  480.       domain for accessories, so the improved path-handling will only show 
  481.       effect when Maus-Window is run as a program.
  482.  
  483.     Changes since V1.24ß:
  484.     - "higher priotity for top-window" now doesn't try to get the "highest" 
  485.       priority any longer. Instead, the priority is raised by 20, and later 
  486.       reset to the old value.
  487.     - "higher priority for top-window" in only selectable when Maus-Window 
  488.       has effective user ID 0 (with "normal" MultiTOS this should always be 
  489.       so).
  490.  
  491.     Changes since V1.23ß:
  492.     - The option "work-area only" had its problems when the windows were 
  493.       not completely visible. This is fixed now.
  494.  
  495.     Changes since V1.22ß:
  496.     - The windows of Maus-Window now are really non-modal, i.e, they now 
  497.       have a closer.
  498.     - the window-dialogs aren't outlined any longer, this saves some space 
  499.       on the screen and is done by most programs.
  500.  
  501.     Changes since V1.21ß:
  502.     - Introduction of the new option "wait for mouse-movement", which e.g. 
  503.       makes sure that after a change of the topmost window caused by 
  504.       keyboard-actions, Maus-Window won't top any window until the mouse is 
  505.       moved again.
  506.     - The main-dialog has been thrown out, the parameter-dialog now appears 
  507.       first and offers a button to call the info-window.
  508.     - Crossed and disabled check-boxes will now (hopefully) always be drawn 
  509.       correctly.
  510.  
  511.     Changes since V1.20ß:
  512.     - Removed stupid bug when running with MultiTOS that caused a hangup of 
  513.       the whole system
  514.     - Added option "higher priority for top-window" for MultiTOS
  515.  
  516.     Changes since V1.17:
  517.     - Maus-Window now is bilingual, i.e., the dialogs and this text exist 
  518.       in German and English. The accessory automatically detects which 
  519.       language to use, for the manual, one has to choose the correct 
  520.       language oneself...
  521.     - For users of KAOS/NVDI 1.x there now is the option "use mouse-click 
  522.       only", which should help against the problem that the mouse-cursor 
  523.       jumps to the left border of the screen instead of topping a window.
  524.  
  525.     Changes since V1.16:
  526.     - The backdrop of MultiTOS and WINX is now supported, but normally, 
  527.       Maus-Window re-tops its windows immediately, if they are accessible.
  528.     - If WINX >= 2.1 is installed, Maus-Window won't use mouse-clicks to 
  529.       top a window, but send a message to the owner of the window (as with 
  530.       MultiTOS). Thus, the button "work-area only" is no longer necessary 
  531.       for WINX >= 2.1
  532.  
  533.     Changes since V1.15:
  534.     - Keeping one of the special-keys (shift, control, or alternate) or the 
  535.       right mouse-button pressed when activating Maus-Window will call the 
  536.       parameter-dialog first. It is no good idea to use control for that, 
  537.       because MultiTOS will then remove the accessory...
  538.     - With AES >= 3.31, Maus-Window no longer uses simulated mouse-clicks 
  539.       top a window. Instead, a new system call (wind_get with WF_OWNER) is 
  540.       used to inquire the owner of the window. A WM_TOPPED-message is then 
  541.       sent to this application. This has the advantage (especially when 
  542.       using MultiTOS), that one doesn't have to activate "work-area only" 
  543.       any longer.
  544.     - Removed some problems with TOS 1.02: I called wind_update once to 
  545.       often which caused a hangup, and made the entry into the desk-menu 
  546.       too late, so it didn't appear in the desktop, first
  547.     - The alert-Box of the "light"-version wasn't correct (I didn't 
  548.       recognize this at first, because I normally use LetEmFly, which 
  549.       corrected my fault automatically)
  550.  
  551.     Changes since V1.10
  552.     - The dialog-window is now splitted into three single windows: main-
  553.       window, parameter-window and info-window.
  554.     - Introduction of new options (prevent coverage of the topmost window, 
  555.       only top when mouse-cursor is still, prevent topping with 
  556.       shift, control, and/or alternate).
  557.     - Introduction of Maus-Window "light", without online-setting of 
  558.       options, but with heavily reduced code-size.
  559.     - Completely rewritten manual (but I still don't like it very much)
  560.  
  561.     Changes since V1.02:
  562.     - Maus-Window has been completely rewritten. It now has a non-modal 
  563.       window for the settings which can also be operated with the keyboard.
  564.     - Maus-Window also runs as a program, but this is only useful in a 
  565.       multitasking-environment.
  566.     - It's now possible to choose, if, as introduced in version 1.02, a 
  567.       window is only topped when the mouse-cursor is located over the work-
  568.       area of the window.
  569.     - It's possible to save the settings of Maus-Window (on/off, work-area 
  570.       only yes/no) as a parameter-file which is read on startup
  571.  
  572.     Changes since V1.01:
  573.     - Maus-Window only tops a window, if the mouse-cursor is located in the 
  574.       work-area (this prevents Maus-Window from operating the gadgets of 
  575.       background-windows when using WINX or MultiTOS)
  576.  
  577.     Changes since V1.00:
  578.     - Maus-Window now waits a bit longer between two tests if a window has 
  579.       to be topped (so one has better chances to move over a background-
  580.       window without topping it)
  581.     - There have been (and still are) problems with the AES, which 
  582.       sometimes stop generating timer-events for Maus-Window. In that case, 
  583.       Maus-Window can't top any window (help: select Maus-Window's 
  584.       accessory-entry, after that, everything's fine again). I don't know 
  585.       why this happens, but I' quite sure it's due to a bug in the AES, 
  586.       since this doesn't happen with MultiTOS. Nevertheless, this problem 
  587.       now appears less often.
  588.  
  589.  
  590.     Have fun with Maus-Window!
  591.  
  592.