@database VisualPrefs_eng.guide @rem $VER: VisualPrefs_eng.guide 1.6b (15.12.97) by Massimo Tantignone @width 72 @wordwrap @node MAIN "VisualPrefs documentation" @{b}VisualPrefs 1.3b (15.12.97) by Massimo Tantignone@{ub} @{" Overview " link OVERVIEW} @{" Requirements " link REQUIREMENTS} @{" The installation " link INSTALLATION} @{" The usage " link USAGE} @{" Notes & hints ;-) " link NOTES} @{bg fill}@{fg filltext} New! @{bg back}@{fg text} @{" Is that all? " link ISTHATALL} @{" How to register " link REGISTER} @{" Translations " link TRANSLATIONS} @{bg fill}@{fg filltext} New! @{bg back}@{fg text} @{" Thanks " link THANKS} @{" Future plans " link FUTUREPLANS} @{" Known problems " link KNOWNPROBLEMS} @{" Conclusion " link CONCLUSION} @{" Program history " link PROGHISTORY} @{bg fill}@{fg filltext} New! @{bg back}@{fg text} @{" Author information " link AUTHORINFO} @endnode @node OVERVIEW "What is VisualPrefs?" WHAT IS VISUALPREFS? ==================== @{b}VisualPrefs@{ub} is a patch which allows you to customize with great freedom many aspects of the look of the Amiga GUI. If you do want to see for yourself what VisualPrefs is able to do, just take a look of the preview image supplied with this archive. Using a comfortable preferences editor, you can configure many details like: · @{b}different@{ub} light/dark colors for active or inactive windows edges · the thickness of all four window borders (also with system gadgets) · the height of window/screen titlebars @{b}regardless@{ub} of the font used · the style of system gadgets · the style of MUI/KingCON/ClassAct/DirOpus/Scalos @{b}titlebar@{ub} gadgets · the exact look of the BOOPSI and GadTools 3D frames · the look of GadTools proportional gadgets · the position of window titles (centered in dragbar or in whole titlebar) · the fill color of @{b}inactive@{ub} window borders ... and also other interesting things. By the way, VisualPrefs contains all the functionality (and more) of my previous patches Prop3D and CenterTitles. You can configure @{b}individually@{ub} the GUI of @{b}each@{ub} different screen opened by your applications, as well as define a global GUI look. I know there are other programs doing some of this, but none of them has @{" all the features " link FEATURES} offered by VisualPrefs. This program is shareware, but you can use it for a while without having significant @{" limitations " link LIMITATIONS}. Also, the registration fee is very small ($6/10DM if you want the keyfile by e-mail, $8/14DM if you want it by normal mail). Please @{b}read carefully all of the documentation@{ub}, as there are some things about VisualPrefs that you need to know before using it. Due to my studies, I can't promise anything about the future development of VisualPrefs (except that there will be some). Probably it will proceed very slowly. BUT, I will do anything in my power to fix any bugs you should find in the current version as soon as possible. @endnode @node FEATURES "All the features of VisualPrefs" FULL LIST OF ALL THE FEATURES OF VISUALPREFS ============================================ o Seven new pens for a more accurate GUI rendition. These pens can be chosen independently for every screen, including the Workbench one. o Possibility to define different shine/shadow pens for active and inactive window borders. Never again those white and black edges! Now you can have windows with plastic-looking borders, similar to the X-Windows look (example: borders with a mid-blue background and light/dark blue edges). o Possibility to set the fill color of inactive window borders. This, together with the previous feature, gives you complete control on the window borders appearance. o Ability to always keep square the screen and window titlebar gadgets. Now, even with large fonts, you won't have those ugly tall & narrow gadgets in the titlebar anymore. o Ability to increase the screen and window titlebar height without changing the screen font. o Possibility to change width and height of the sizing window gadget, as well as of the arrow gadgets. This allows to modify the thickness of right and bottom window borders to finally have a correct aspect ratio even with square-pixel (1:1) screenmodes. Window borders up to 32-pixel thick! (Useful for very high resolutions, like 1600x1200...) o Possibility to set the desired thickness for each of the four window borders also when they don't contain system gadgets. Now you can have, for instance, top and bottom window borders four-pixel thick just like the left and right ones, rather than two-pixel thick as usual. o Four (for now) different system gadget styles: Standard (but with fully scalable images), XEN (like SysIHack), and two new styles among which there is one that loosely resembles the NeXTStep look (or, if you REALLY want, the Windoze95 look :). o You can choose to have "normal" scrollbars, scrollbars with a recessed frame, scrollbars with a knob hole, or both (SysIHack-style). [Note: the knob hole is only possible with BOOPSI propgadgets.] o Possibility to freely configure the look of GadTools gadgets frames (and, more generally, of all BOOPSI frames). Simple borders, double borders, two-color borders, rounded borders, XEN borders, with any background color, even a dithered one. Furthermore an optional new mode to render "pressed" gadgets, more realistic than to simply switch the border colors. o Possibility to also modify the look of the gadgets added to the titlebar by MUI, KingCON, ClassAct, ViNCEd, DirOpus and Scalos. o Compatibility with the KingCON scroller: forever gone the "overlapping arrow gadgets" problem. The same applies to SCMSG, SE and CPR. o All the capabilities (and more) of my previous Prop3D patch are directly integrated. You can configure every aspect of GadTools proportional gadgets and arrow buttons! o You can now choose the look of GadTools cycle gadgets. o Window titles can be placed in the center of the dragbar or in the center of the whole titlebar, just like with the CenterTitles utility. :-) o Possibility to define the color used to draw the symbols contained in window border gadgets (except for the XEN/SysIHack style which uses instead 3D images). o Possibility to fill the recessed areas of XEN 3D images with the desired color. o You can modify the preferences with a comfortable editor featuring a preview zone similar to the one of the system Palette editor. o Possibility to save default settings but also custom settings for particular screens. Example: Wordworth, PageStream and TypeSmith don't support window borders with a non-standard thickness? No problem, you only have to change the settings for their screens. o The preferences editor allows you to edit all system standard pens (like backgroundpen, textpen, fillpen...) of the Workbench screen and to save them in a way that is totally compatible with the Palette editor. In fact, together with another program (FullPalette) which you can find on Aminet, it becomes a complete replacement for said editor. For other screens, instead, it's only possible to modify the added pens (to avoid to interfere with the handling of the GUI preferences done by the programs which opened them). ----------------------------------------------------------------------------- In the future it is very likely that I'll add the ability to load custom images from disk for window border gadgets; how soon this will happen depends on how many people will request it. The same holds true for any other idea that will be suggested to me. @endnode @node LIMITATIONS "Limitations of the unregistered version" LIMITATIONS OF THE UNREGISTERED VERSION ======================================= In the unregistered version there are no disabled features, but: · You can only save/use up to 10 (ten) screen definitions; · If you save more than 5 (five) screen definitions, a requester will appear each time you run the GUI editor; · Only two screens at a time can use the global template. That's it. If you want unlimited screen definitions, unlimited template use and no requesters, please consider @{" registering " link REGISTER}! :-) @endnode @node REQUIREMENTS "Requirements for VisualPrefs" REQUIREMENTS FOR VISUALPREFS ============================ An Amiga computer with AmigaOS 3.0+. A display mode with square (1:1) pixels is strongly suggested, as well as a screen resolution of 640×400 or more. Also a graphic card could be useful (but not required). @endnode @node INSTALLATION "How to install VisualPrefs" THE INSTALLATION ================ The installation is very simple; just use the supplied Installer script. If you want to do a manual installation, follow these instructions... First of all, copy the following files onto your hard disk: +-------------------------------------------------------------------------+ | VisualPrefs To any directory (for example C:) | | Prefs/GUI To SYS:Prefs | | Prefs/GUI.info To SYS:Prefs | +-------------------------------------------------------------------------+ If you want, you can also copy the "GUISample.pre" file to SYS:Prefs/Presets, but it isn't really mandatory. Now you must add a line to your Startup-sequence (alas, it is not enough to put it into User-startup), IMMEDIATELY BEFORE the one with the "C:IPrefs" command: ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Run > NIL: /VisualPrefs Where is the name of the directory VisualPrefs resides in. Example: +--------------------------+ | ... | | Run > NIL: C:VisualPrefs | | C:IPrefs | | ... | +--------------------------+ Finally, if you were using the programs "Prop3D" and/or "CenterTitles", @{b}remove@{ub} them from your User-startup or WBStartup drawer. @endnode @node USAGE "How to use VisualPrefs" THE USAGE ========= After the installation you must reboot. Then you can begin to use the GUI editor to modify the interface's look. I advise you to "play" a little with the editor at this point, before coming back here to read the rest of the documentation. In fact, the editor is rather intuitive, however there are some important things to speak about that will be more understandable if you already know the editor's basic structure. Note: the term "DrawInfo pens" refers to the pens (colors) used for the various elements of the GUI, such as light/dark edges, text, background, etc. You find the list of DrawInfo pens at the left side of the editor window. @{" The GUI editor " link GUIEDITOR} @{" Editing the GUI of single screens " link EDITGUISS} @{" Defining a default configuration " link DEFDEFCFG} @{" The pen mode " link PENMODE} @{" Color locking " link COLORLOCKING} @{" Special patches " link SPECIALPATCHES} @{" Global options " link GLOBALOPTS} @{" Limitations of the unregistered version " link LIMITATIONS} @endnode @node GUIEDITOR "The GUI editor" The GUI editor -------------- With the editor you can set many aspects of the GUI, like the DrawInfo pens, the style of window border gadgets, the width and height of the window sizing/arrow gadgets and the exact look of gadget frames. At the right side of the GUI editor's window there is a listview with several options to configure the basic appearance of the gadget and window frames. Above it is a preview display reflecting the current settings. At the top left side of the editor's window there is a cycle gadget allowing you to flip through various configuration pages for specific aspects of the GUI look and behavior. These pages, also, can have sub-pages. Above it is a text display gadget indicating the name of the current screen, with a chooser gadget ("<") to go to the @{" screen selection section " link EDITGUISS}. Note that the effects of the various options in the listview at the right side of the editor's window depend also on the colors you've chosen for the screen's DrawInfo pens. If you choose the same color for more than one pen, some options will seem to have no effect! The cycle gadget below the palette has a special purpose that will be explained in the section "@{" The pen mode " link PENMODE}". @endnode @node EDITGUISS "Editing the GUI of single screens" Editing the GUI of single screens --------------------------------- You can edit the parameters of single screens. You can select the screens to edit by clicking the "<" gadget in the top left of the window. Then you can double-click on a screen name from those in the listview. For a screen to be edited the first time, it must of course be already open, otherwise it won't appear in the listview. Any subsequent time the editor will open a clone of the screen if the "real" one is not open. Names of screens not already saved in the preferences file will appear in a "highlight" color. You can also inhibit VisualPrefs from operating on certain screens, by clicking on the cycle gadget ("Patch"/"Ignore") at the bottom right of the window. If you select "Ignore", the name of the screen will appear recessed and VisualPrefs won't patch it at all. VisualPrefs recognizes screens by comparing their public name (or title if they aren't public) with the name saved with the GUI editor. You can modify this name with the string gadget; in particular, to make it match a larger class of screens, you can add a #? at the end. This is NOT true pattern matching, however: wildcards don't work @{u}inside@{uu} the name, only at the end (and only the "#?" couple). You can delete a screen definition using the "Delete" gadget, but only if the GUI editor is not present on the corresponding screen. Also you can't delete the definition for the Workbench screen. If you attempt to do so, an error message will be displayed. If the screen associated to the definition you delete is still open, its name will remain in the list, but it will return to a "highlight" color, which indicates its definition won't be saved into the preferences file. For any change to take effect, you must then click on "Use" or "Save" on the main editor panel. Note that the GUI editor remembers the settings of all "visited" screens, so you'll need to select "Use" or "Save" only once at the end of your editing session. VisualPrefs will attempt to close and re-open the Workbench screen each time you change something significant in its configuration; screens of other applications will have to be manually closed and re-opened for all changes to be correctly applied. @endnode @node DEFDEFCFG "Defining a default configuration" Defining a default configuration ------------------------------- You can define a default configuration ("template") which will be used for all screens lacking an entry in the preferences file. To do this, just edit the parameters of any screen to reflect your desired default settings, then select "Save as template" (or "Use as template" for a temporary change) from the "Project" menu. You'll be asked some @{"questions" link TEMPQUESTIONS} about how the DrawInfo pens will have to be determined by VisualPrefs for the various screens, then your default template will be saved. DON'T click on "Save" or "Use" now, but simply quit the editor, or else the default template will also be saved as the current screen's settings! @endnode @node TEMPQUESTIONS "Save options for the global template" Save options for the global template ------------------------------------ When you save the configuration for the global template, one or two requesters will appear asking you some questions about the method to be used for the choice of DrawInfo pens on different screens. This is necessary as each screen has its own particular palette, so it isn't convenient to always use the same "fixed" pen settings for all screens. In the following text, "current screen" means "the screen on which there is currently the GUI editor window", whereas "destination screen" means "the screen to which the template will be applied". The first requester asks if you want to save the current pen settings with the template, and offers two choices: "Save pen settings" means the current screen's pen settings will be saved along with the template; this way, the destination screen's pens will be chosen in a way that respects those settings as much as possible. "Find pens automatically" means the destination screen's pens will be assigned some suitable values which only depend on the already existing (system standard) DrawInfo pens of the screen itself. This guarantees an acceptable look, although not always the best possible one; anyway, if in doubt, you should probably choose this answer. If you've chosen "Save pen settings" another requester will come up, asking how missing pens (that is, pens of the destination screen which, if they were to keep the same index, would have a visually different color than the one they have on the current screen) will have to be "reassigned". You have three possible choices: "Find best match" means VisualPrefs will try to assign the pens those colors which most resemble the ones assigned to the current screen's pens, even if they don't have the same index values. "Use selected values" means the destination screen's pens will use exactly the same color index values as the current screen's pens, even if the actual colors don't look the same. "Use fallback values" works the same as "Find pens automatically", but only for the missing pens (the pens which already have a correct color will be left alone). @endnode @node PENMODE "The pen mode" The pen mode ------------ As you already know, each DrawInfo pen has a color index associated to it. VisualPrefs, with its GUI editor, allows you the greatest flexibility in the selection of colors for the DrawInfo pens of a screen. Why? Some screens, when they change their depth, remap the colors of their palette in a different way than others (the Workbench screen is a perfect example of this, as it always remaps four of its eight colors to the end of its palette). So it's not always sufficient to simply assign a fixed color index to a pen. For this reason, each pen has a "pen mode" that determines how its color index is recalculated when the screen's depth (i.e. number of colors) is different than what it was the LAST TIME you used the GUI editor on it to edit (and save) the pen's color. To set the pen mode of a pen you use the cycle gadget ("Absolute"/"Relative") located below the palette in the "Pens" page of the GUI editor. Let's see how this works; we'll indicate with "n" the generic number of colors of a screen. 1) If the pen mode is "Absolute", the pen will always use exactly the absolute index of the color AS IT WAS WHEN YOU SELECTED IT; this can go from 0 to n - 1. If, later, this color index doesn't exist on the current screen because there are too few colors, the result is undefined (most likely the wrong color will be used). 2) If the pen mode is "Relative", there are two possibilities: 2a) If the color index, when you selected it, was in the FIRST HALF of the palette (color 0 to n/2 - 1), then it will be treated as in the "Absolute" case, EXCEPT when there are so few colors that, maintaining its absolute index, it would end up in the second half of the palette (or even beyond). In this case, a fallback color index will be used. 2b) If the color index, when you selected it, was in the SECOND HALF of the palette (color n/2 to n - 1), then it will always keep the same offset, i.e. distance, from the END of the palette rather than from the beginning. So, for instance, color n - 3 will always be color n - 3 regardless from how many colors the screen has. Furthermore, if the screen has so few colors that, maintaining its offset from the end, the color would end up in the first half of the palette (or even beyond), a fallback color index will be used. In the case of the Workbench screen, for example, you should set "Absolute" for pens using the first four colors and "Relative" for pens using the last four. What you should do for pens using other colors in-between depends on many factors, one of which is whether or not you use some utility allowing you to set and lock all of the Workbench colors (rather than just eight of them like the standard Palette editor does). @endnode @node COLORLOCKING "Color locking" Color locking ------------- As some programs change their palette while running (for example web browsers) you could need to lock the colors you assign to VisualPrefs-specific DrawInfo pens. In the "Color locking" page of the GUI editor you can do just that. There you find ONLY colors that VisualPrefs will use and that will NOT be locked automatically anyway by Intuition. Note that this still doesn't guarantee to get the intended color for a pen: if you use color locking, you must also make sure the color you chose already has the desired value when the screen is opened! All VisualPrefs does is to prevent such value from changing @{b}later@{ub}. @endnode @node SPECIALPATCHES "Special patches" Special patches --------------- In the "Global" menu you find some entries that allow you to selectively activate some patches. They can add some overhead to the working of VisualPrefs, so you have a choice whether to use them or not. Select "Patch KingCON" to tell VisualPrefs to patch the gadgets added by KingCON to window borders. Select "Patch AmigaGuide" to tell VisualPrefs to correctly display the text in the toolbar gadgets of an AmigaGuide document (without the patch it is written in JAM2 mode, covering part of the gadget frame). Select "Patch SAS/C" to tell VisualPrefs to patch the gadgets added by SCMSG, SE and CPR to window borders. Select "Patch MagicMenu" to tell VisualPrefs to center (vertically) in the screen bar the menu titles displayed by MagicMenu. This is useful if you have increased the screen bar height. Use this patch with MagicMenu 2.19+ only! With earlier versions it just makes things worse... ;) @endnode @node GLOBALOPTS "Global options" Global options -------------- In the "Global" menu you find some entries that allow you to change globally (that is, for all screens) some aspects of the VisualPrefs behavior. Select "Old XEN look" to tell VisualPrefs to use a XEN style for system gadgets that is more similar to the one of the original SysIHack patch (which first introduced it); otherwise VisualPrefs will use a XEN style that is slightly different from SysIHack's one. For now you will only notice a difference in the sizing gadget. Select "Don't use Template" to tell VisualPrefs NOT to patch any screen which doesn't have a definition in the preferences file; that is, if this option is selected, @{b}only@{ub} saved screens will be patched. @endnode @node NOTES "Important notes and useful hints" NOTES AND HINTS =============== @{b}The most important note of all@{ub}: VisualPrefs works well with all programs respecting the rules, like adapting to the window border sizes, using system functions for creating/drawing gadgets, etc. Of course, badly written programs or programs using proprietary code for their interface (like MUI applications) will benefit very little from VisualPrefs. ___ When using VisualPrefs you should disable all other similar patches, such as SysIHack, UrouHack, MagicFrames and MCP's FrameIHack, SysIHack, PropHack and NewGadTools options (but for this one see also the next note). Also, you should remove my previous Prop3D and CenterTitles utilities. ___ NOTE WELL: If you use the "WBGauge" option of MCP, make sure that the "NewGadTools" option is ENABLED as well, or else there could be a crash (at least with some versions of MCP). You can turn on "NewGadTools" without any conflict with VisualPrefs, as long as you leave deactivated all @{u}individual@{uu} patches. ___ @{bg fill}@{fg filltext} New! @{bg back}@{fg text} VisualPrefs, like most patches, causes a slightly larger stack usage by programs calling the functions it modifies. Normally this isn't a problem, but it is known that the IPrefs program allocates a very small stack for itself and sometimes it could run out of it (for example when using certain datatypes for the Workbench background patterns). If you experience this problem, I advise you to use FastIPrefs 40.35 (util/boot/FastIPrefs4035.lha) as a full replacement of the original IPrefs. Another program that suffers from a small default stack is WShell; to solve this, it suffices to increase the stack size in the DHOpts command using its STACK parameter (DHOpts CON:/xx/yy/ww/hh STACK 8000). ___ @{bg fill}@{fg filltext} New! @{bg back}@{fg text} VisualPrefs can be made nearly 100% compatible with the Birdie patch. This is not automatic, as it requires disabling some optimizations in the code, and this wouldn't make sense if you aren't using Birdie. In order to obtain compatibility with Birdie, you must make sure that: · An environment variable called "VisualPrefs/BirdieMode" exists and contains one of the following two values: FULL if you use Birdie the normal way, or NOBITMAPS if you use Birdie with the same switch. · The Background pen and the Inactive Fill pen are both set to color zero. Furthermore, note that if you have a 15/16/24-bit Workbench, the Glyph pen will be rendered as a @{b}darker@{ub} shade of the window border pattern, unless you set it to be the same as the Shine pen (in which case it will be a @{b}lighter@{ub} shade of the border pattern). All this was tested with Birdie 1.3; I can't guarantee it will continue to work with future version of the patch. ___ @{bg fill}@{fg filltext} New! @{bg back}@{fg text} There's a @{b}bug@{ub} in Intuition 3.0/3.1 which can cause a deadlock when VisualPrefs reopens the Workbench screen after a change to its settings. This problem shouldn't happen very often, but if you experience it, you can try to avoid it by telling VisualPrefs to wait a little before reopening the screen. Just set the environment variable "VisualPrefs/WBOpenDelay" to a number indicating the duration of the delay. A value of 50 means a second, 100 is two seconds, and so on; normally it should suffice 20 or less. (Note: previously this was believed to only happen with Picasso96.) ___ If you use NewIcons, make sure it is launched @{b}after@{ub} VisualPrefs at the boot, or else its "No borders" function won't work properly. ___ For better results with VisualPrefs, use MagicMenu 2.19 or greater; versions up to 2.15 display the menu bar incorrectly if the titlebar height has been increased. ___ To patch the "iconify" gadget of ClassAct programs, you must select the "Normal" border gadget in the ClassAct preferences editor; if you select "3D" the patch won't work. ___ VisualPrefs works best with 1:1 resolutions (i.e. with square pixels). With other resolutions it works, but the results aren't always optimal. Furthermore, in low-res (320×???) it still has some problems (better to set such screens to "Ignore" in the screen list). Also, keep in mind that the GUI editor needs some space for its window; on small screens its user interface may not fit entirely. If this happens, try reducing the size of its font with the FONTNAME and FONTSIZE tool types. ___ VisualPrefs greatly benefits from an utility allowing you to define and lock ALL Workbench colors, as opposed to just eight of them like you can do with the standard Palette editor. There are several such utilities on Aminet, and there is also one written by me, "FullPalette", available on Aminet as util/wb/FullPalette19.lha (as I write this; the trailing number, 19, could have changed by now). Of course I suggest you use this one. :-) @endnode @node ISTHATALL "Is that all?" IS THAT ALL? ============ No. I certainly forgot to mention something, so if you have any problem with the usage of VisualPrefs and/or the GUI editor, don't hesitate to ask me for clarifications. @endnode @node REGISTER "So you want to be a registered user?" HOW TO REGISTER TO VISUALPREFS ============================== Please read @{b}carefully@{ub} the following text! The method of registration is very simple. You only have to print the @{" registration form " link REGFORM}, fill it in and send it to @{" me " link AUTHORINFO} along with the required sum of money. The registration fee is: · $6 (10 DM, or equivalent) for shipment of the keyfile by e-mail, or · $8 (14 DM, or equivalent) for shipment of the keyfile by normal mail. For now I allow you to pay me in any currency, although in the future this could change. Of course, if you pay me in italian Lire I will be happier... :) You can choose between various methods of payment: o Send money in an envelope, together with the registration form o Make an international postal money order, and send the registration form in an envelope (specify "VisualPrefs registration" on the money order form) o Make a bank draft, and send it in the envelope together with the registration form (@{b}please@{ub}, first verify that your bank draft can be cashed in Italy) Sorry, at the moment I can't accept credit cards. If you really want to, you can also send me the registration form via e-mail, to make sure I receive your order, however this is mostly useless. But PLEASE put it ALSO in the envelope with the money or bank draft. You can choose whether to receive the keyfile via e-mail or via normal mail. o If you decide to receive it via e-mail, please specify your e-mail address on the registration form. o If you decide to receive it via normal mail, please enclose a @{b}pre-formatted@{ub} floppy disk (DD or HD) into the envelope. I will ship you the keyfile as soon as I have received BOTH the registration form AND the money. If you request a shipment via normal mail, please allow 2-8 weeks for delivery. I'll repeat my address here: Massimo Tantignone Via Campagnoli, 4 28100 Novara (NO) ITALY If anything is not clear, please write to me for more information. Thank you! @endnode @node REGFORM "VisualPrefs registration form" VISUALPREFS REGISTRATION FORM ============================= Please print and fill in this registration form, then send it together with the payment to: Massimo Tantignone Via Campagnoli, 4 28100 Novara (NO) ITALY @{b}8<-------------------------------CUT HERE----------------------------------@{ub} ====================== VisualPrefs registration form ====================== ======================== valid for all countries ======================== -------------------------------------------------------------------- ---- Please mark with an 'X' the boxes relevant to your choices ---- -------------------------------------------------------------------- I would like to become a registered user of VisualPrefs. To this purpose, along with this registration form, I'm sending (enclosed in the same envelope, or separately if this form is sent via e-mail): [ ] The required sum of money (see below) as cash [ ] A bank draft for the required sum of money [ ] A document certifying the payment of the required sum (example: receipt) [ ] Nothing, because I have sent/will send a postal money order I acknowledge that the required sum of money for the registration is: · $6 (10 DM, or equivalent) for shipment of the keyfile by e-mail, or · $8 (14 DM, or equivalent) for shipment of the keyfile by normal mail. So, I want to receive my personal keyfile, as soon as possible, by: [ ] Electronic mail (e-mail) at the address specified below [ ] Normal mail (please enclose a pre-formatted floppy disk) If the keyfile is sent via normal mail, I allow 2-8 weeks for delivery, starting from the day the author will have received both the registration form and the money. My personal information is: First name ___________________ Last name ______________________ Street ________________________________________ Number ________ City _______________________________ State ____ ZIP ________ Country __________________________________________________________ E-mail address ________________@__________________________________ VisualPrefs version I'm using ____________________________________ (Optional) Configuration of the Amiga(s) I own ___________________ __________________________________________________________________ I guarantee that the keyfile I will receive won't be distributed and will be used only by me on one or more computers owned by me. Date __________________ Signature _____________________________ @endnode @node TRANSLATIONS "Translations to other languages" TRANSLATIONS ============ @{bg fill}@{fg filltext} New! @{bg back}@{fg text} I'm already in touch with some people for a translation of the catalog and documentation to other languages. All translations are currently being made or will be very soon. So, currently I don't need any new translators! Thank you anyway :-) Almost certainly, all translations will appear (together or individually) in separate archives on Aminet when they are ready. @endnode @node THANKS "Thanks to..." THANKS TO... ============ Many thanks go to my faithful (well, most of them anyway :) @{b}beta-testers@{ub}, without which the development of VisualPrefs would not have been possible. They are, strictly in alphabetical order: Alex Pagnoni Amedeo Brunetti Cristian Castellari Daniele Franza Davide Benuzzi Davide Pellegatti Donato Filippo Rasmussen Eugenio Gori Fabio Rotondo Federico Pomi Francesco Leoni Gabriele Favrin Gabriele Greco Giorgio Maone Giuseppe Ammendolia Greg Baldwin Lorenzo Morselli Luca Danelon Luigi Catuogno Marco De Vitis Matthew Gregan Mirco Zanca Nik Soggia Paolo Lencioni Paolo Luzi Riccardo Giangualano Roberto Braidotti Rudi Chiarito Simone Tellini Stefano Dardari Ubaldo Flora Thanks again to all of you! Special thanks also to Thomas Richter, for his kind cooperation in making ViNCEd fully VisualPrefs-compatible. :-) @endnode @node FUTUREPLANS "Future plans for VisualPrefs" FUTURE PLANS FOR VISUALPREFS ============================ Well... certainly I would like to add more image styles, the ability to use custom bitmap images for system gadgets, new windows and gadgets capabilities, and so on. Also, an interface for developers would be an interesting idea. How much of this will be done depends on several issues, in particular: 1. How much time my studies will allow me to spend into Amiga programming; 2. Which features the future AmigaOS GUI will already have; 3. What kind of feedback I will receive from Amiga users. So, if you want to see new features added to VisualPrefs, please @{b}register@{ub}! ;) @endnode @node KNOWNPROBLEMS "Known bugs and problems of VisualPrefs" KNOWN BUGS AND PROBLEMS OF VISUALPREFS ====================================== Ahem. Here you'll find some information about the problems you may currently encounter using VisualPrefs. o Certain windows of some MUI programs (like IBrowse) appear empty if the top border's thickness is different than (titlebar height increment + 2). This is really a nasty problem, I don't know if I will ever be able to find a solution. For now, set the top border to a value == (titlebar height increment + 2). o MagicMenu 2.19+ will always display the menu bar with the correct height, but the menu titles aren't centered vertically within it. So, for now it is necessary to use the "Patch MagicMenu" option of VisualPrefs to obtain the centering. I've already explained the problem to the author of MagicMenu and hope he'll address it soon. o Prop3D seemed to cause problems when used together with ARQ _AND_ MagicMenu, but I haven't been able to reproduce this bug yet. Now let me know if this still happens with VisualPrefs. o There are still some quirks in the GUI editor which I've been thus far unable to trace. Keep those bug reports coming... ;) o Display problems using Thor on the Workbench screen. It turned out this isn't due to VisualPrefs per se, but only to the choice of colors for your shine/shadow/fill pens. If you have this problem, try to select pens that are all as "near" as possible in the palette. In particular, it should work if all of the pen indices give the same remainder when divided by 4 (example: pens 4, 5, 6 and 7). @endnode @node CONCLUSION "Conclusion" CONCLUSION ========== When you'll encounter a bug/problem/whatsoever, report it to me writing @{b}as much details as possible@{ub} on what happened and on your system configuration at the time, including any patch or commodity running in background. It's possible I already know about some bugs, but that they can't be fixed due to current limits of Intuition. Please write also to say VisualPrefs works well on your systems, if it does! You can also write suggestions for future enhancements, but keep in mind that I must always give absolute precedence to the elimination of bugs. In fact, I'm not even sure to which extent it will make sense to continue the development of this patch, because, whatever will be the successor of the current AmigaOS, it probably won't need VisualPrefs anyway (I hope!). So, for now I think it's more important to remove bugs and problems of the current version. If you are an english speaker, please check the correctness of this documentation and report to me all grammatical or syntactic errors. ;-) In the end, remember that VisualPrefs is an "ongoing" project and as such it can always undergo changes of plans (alas, sometimes they don't depend on my will). I apologize for not being always able to answer your mails immediately, but my studies don't allow me to use my Amiga as often as I would like to. However, I do my best to answer ALL e-mail eventually. That said, have fun with VisualPrefs! Massimo Tantignone (tanti@intercom.it) [http://www.intercom.it/~amigaws] @endnode @node PROGHISTORY "The history of VisualPrefs" THE HISTORY OF VISUALPREFS ========================== @{b}1.3b (15.12.97)@{ub} Small update: · Compatibility with Birdie in hi-color and true-color modes was broken due to the previous bug-fix. Now it works again. @{b}1.3a (12.12.97)@{ub} Small update: · Fixed an odd bug which prevented VisualPrefs from running on most V39 (Kickstart 3.0) systems. · Slightly modified the documentation. @{b}1.3 (26.11.97)@{ub} Bug-fixes: · Fixed a bug that caused the YAM mailer to display fake error messages. · Now the iconify gadget of the DirOpus text reader window is also patched. · The DirOpus screen title wasn't always vertically centered. Now fixed. · Removed an Enforcer hit with DirOpus 4. · Now the additional titlebar gadgets (such as the MUI ones) have the correct colors on Picasso96 hicolor and truecolor screens. · The previous fix for the YAM problem, found on my home page, did cause address errors on plain 68000 CPUs. Now fixed. · With big titlebar gadgets, sometimes the window title covered part of the gadget at its immediate right. Now fixed. · Saving the preferences doesn't corrupt anymore the titlebar of some screens if they have an increased titlebar height. · Now deadlocks at the reopening of the Workbench screen when saving the preferences should be less likely to happen. Enhancements: · Now VisualPrefs can be made nearly 100% compatible with Birdie! See the documentation to learn how to obtain this. · Now the KingCON patch also works for RAW: and KRAW:. · Now VisualPrefs also patches the Scalos iconify gadget image. · Added some developer documentation about the "tbiclass" image class. @{b}1.2a (22.10.97)@{ub} Small update: · Fixed a bug in the installation script. · The "Flat" screen depth gadget image now uses the Bar Detail pen if the Glyph pen and the Bar Block pen have the same value. · Fixed a bug in the look of the inactive "padlock" image in the "Standard" style. @{b}1.2 (18.10.97)@{ub} Bug-fixes: · The patch for the ClassAct iconify gadget didn't work with the latest release of ClassAct. Now this is fixed. · The workaround for the V39 gadtools.library bug didn't work very well, so I found another one. Enhancements: · Now VisualPrefs patches DirOpus 5.5+ titlebar gadgets. Only tried it with Magellan, but it should work also with previous releases. Hope you like the new "padlock" image... · Renamed "iconifyimageclass" to "tbiclass" to comply with the new API of ViNCEd. Now VisualPrefs should be 100% compatible with ViNCEd (3.53+). · Now you can choose to install a 68020/030 or 68040/060 version of VisualPrefs and GUI. · Some optimizations to the code of certain patches. · Of course, this release also contains all the changes introduced in release 1.1, which wasn't released on Aminet (see below). @{b}1.1 (3.10.97)@{ub} Some bug-fixes: · No more crashes with MUI "screen close" gadgets. · The screen titlebar doesn't get corrupted anymore under CyberGraphX 3 with the SUPERLAYERS option on. · The GUI editor now correctly fills the bottom scroller's hole in the preview area if you select the "Fill recessed areas..." option. · Now the GUI editor allows for fonts with an height smaller than 7 pixels; the new limit is 5 pixels. · GadTools arrow gadgets didn't get patched if their width or height was smaller than 10 pixels; now the limit is 9 pixels. · The image of CheckBox gadgets sometimes did overwrite part of the border. · Added a workaround for a bug in the V39 gadtools.library concerning the displaying of the contents of number gadgets. Hope it works! · The "Global" menu is now correctly updated when you select "Last saved" from the "Edit" menu. Enhancements: · The rendering of MUI titlebar gadgets should now be somewhat faster. · Added a patch for MagicMenu 2.19+ allowing to vertically center the menu titles in the screen bar. · Added the possibility to inhibit the use of the Template. · Added public "iconifyimageclass" image class for use by programs such as ViNCEd. @{b}1.0a (26.7.97)@{ub} Small update: · Fixed some bugs in the installation script. · Added a few more safety controls in the GUI editor. · There were some cases in which the Workbench screen would lock up if closed and reopened. Now this shouldn't happen anymore. · Slightly modified the documentation. @{b}1.0 (23.7.97)@{ub} First Aminet release. @{b}Beta releases #1 to #7@{ub} Private beta-tester releases. @endnode @node AUTHORINFO "Some information about the author of VisualPrefs" AUTHOR INFORMATION ================== Massimo Tantignone Via Campagnoli, 4 28100 Novara (NO) ITALY E-mail: tanti@intercom.it WWW: http://www.intercom.it/~amigaws @endnode