QED Copyright 1989 by Darren M. Greenwald. QED is a SHAREWARE; freely distributable Amiga text editor. Last revised 5/22/89 General notes, comments, questions, and answers from the author of QED. ----------------------------------------------------------------------- Over the past few weeks I have received several questions which repeatedly keep coming up. Rather then answer the same questions over, and over again, I have decided to use this file for this purpose. ----- QUESTION - Why can't I use the LEFT AMIGA key in place of the RIGHT AMIGA key to select menu items? ANSWER - The LEFT, and RIGHT AMIGA keys belong to the operating system. Intercepting these keys, or otherwise changing their functions is NOT a recommended Amiga programming practice. In fact we are likely to see much more use made of the LEFT AMIGA key by the operating system under version 1.4 of the operating system. Intercepting the LEFT AMIGA key is sure to result in contention issues under 1.4. Starting with beta version 0.14 of QED, the ALT keys are automatically mapped to imitate the RIGHT AMIGA key alternatives listed in the pull-down menus. Prior to this version, the CTRL key was mapped to imitate the RIGHT AMIGA menu keys. This is both a valid programming practice, and allows you to use either hand. ----- QUESTION - How come LEFT AMIGA M/N don't work unless I have another screen open? ANSWER - LEFT AMIGA M/N is an operating system feature which moves the Workbench screen to front & back. It never does anything unless you have another screen open. QED runs on the Workbench screen; not its own screen. ----- QUESTION - How come I can't respond to QED's requesters using LEFT AMIGA V/B? ANSWER - LEFT AMIGA V/B is an operating system feature which allows you to respond with a yes/no response to "AUTOREQUEST REQUESTERS" such as the type used for system requesters. QED does not use Auto Requesters because I find them unattractive, and far too limited for the needs of the program. Auto Requesters also do not allow for the use of string gadgets. As stated above, the LEFT & RIGHT AMIGA keys belong to the operating system. Application programs should not be intercepting, or otherwise fiddling with system capabilities - this is the kind of programming practice which often results in a program not working under later revisions of the operating system. Re-read page 3 of your 1.2 enhancer manual (at the top labeled - Page 4-30:). Note that this capability works for Autorequesters only; it was never intended to work for application specific requesters. Therefore, I will not attempt to imitate such a feature until such time as it becomes an operating system feature. In the mean time, use of the 'o', and 'c' keys is both easy, and rapidly becomes natural. Once you become use to it, you'll wish every program made it so easy. When a string gadget is active, it is not possible to obtain key press messages without a great deal of system fiddling; the proper way to respond to string requesters is with the RETURN key, and/or the other editing keys which string requesters recognize. ----- QUESTION - The file requester appears to be missing file/sub-dir names? ANSWER - File requesters vary significantly in the Amiga software world. Some sort file names, some dont. Some make you wait for the entire directory to be read, some dont. Some separate the files from the sub-directories, some dont. Etc... There is really no "convention" as of yet. Few people can agree on how a file requester should behave, and often users are rather confused by the issues involved (the kinds of issues which programmers can spend hours discussing). No, QED's file requester is not missing file, or sub-directory names, however, the list of names is not immediately redisplayed until the user slides the proportional gadget. Why? Many Amiga file requesters still make you wait for the entire directory to be read before displaying anything, and some don't even allow you to enter a file, or path name until the entire directory has been read. This is often painfully slow for floppy users. Some requesters, including QED's, solve this problem by allowing you to select a file/sub-dir before the entire directory has been read. However, it is my opinion that some programmers have not given this approach enough consideration. The problem is that some requesters will continually, or periodically redisplay the list of file/sub-dir names. Often this occurs just as you are ready to click on a name, or just after you have finished moving the proportional gadget to display the name you are looking for. The net result is that you end up having to wait for the entire directory to be read anyway as the list of names often changes faster then you can read, or select. Worse, it takes additional time to continually redisplay the list of names meaning it actually takes longer to read the entire directory! While it is often "cute" to watch the list of file/sub-dir names continually change, it is also a pointless waste of time. At best the user gets lucky, and can click on a name before the list is updated. Often it is just not worth even trying, and the user gets to wait even longer for the entire directory to be read. ----- QUESTION - How about adding more features to the file requester? ANSWER - At one time, I was working on the "ultimate" file requester for QED. Without even thinking it somehow seemed important that QED have an "ultimate" file requester. As the features were being added, the size of the requester just kept growing, and growing... all of this for what? In order to select a file name! At some point I realized I had lost sight of my original goal; namely to write a relatively small, fast, and efficient text editor. I use a text editor daily, and only a small fraction of that time is spent selecting file names. So is it worth it to write a huge chunk of code for the sole purpose of selecting a file name; an operation which takes just a few moments? The "ultimate" file requester should at least be available via a shared library, and not replicated in every program. Yet despite the apparent simplicity of QED's file requester, it has features which many other file requesters don't. Memory is dynamically allocated, and deallocate for the directory entries, and device list. So large directories, or device lists are no problem. Many requesters can't handle device names which are longer then 3 characters in length, however device names can be as long as 31 characters in length; QED handles this just fine. Also the size of all of QED's requesters (including the file requester) are adjusted to use your system font. This includes adjusting the size of the windows, gadgets, borders, etc. Many requesters just look awful when using a system font other then Topaz 8. ----- QUESTION - QED does not recognize a font change using NEWFONT? ANSWER - The only program which "properly" adjusts the system font is Preferences. QED has been successfully tested with Preferences, Setfont2, and FF by MicroSmiths, Inc. There is however a bug in Setfont2 which is apparent system wide in string gadgets. This is evidenced by 2 different fonts being used in string gadgets; 1 when the string gadget is active, and another when inactive. This is a bug in Setfont2, and cannot be corrected by QED, however it appears to be relatively harmless.