CompuServe Thread

#MagicWB observations

7 messages in this thread
#109615From: Brian BartlettAug 6, 1993 10:07 PM
All, just a few observations concerning MagicWB (Magic.lzh). The update went very smoothly, but I thought I should drop some tips here after my long update session. Since I'm using an A2000/3001, I think that most of what follows will help those with similiarly limited (chipmem-wise) machines. First off, if you don't have Find (by Larry Phillips) I highly recommend that you get it. The same applies to some type of disk reorganizer. The former will allow you to find your icon files which will require updates while the latter will speed up the rendering of icons whenever you open a drawer. Make no mistake, MagicWB _will_ load down any machine that doesn't have the 32 bit wide chip ram, which should be no suprise to those that have had an eight-color workbench for a while. On the other hand, it is easily worth the small degradation in speed. So far, the degradation amounts to about 5-10% here, but your mileage may vary <g>. There is also one more slight problem related to the eight-color workbench and that has to do with large drawers. I don't know about you, but I've collected quite a collection of programs in my C: directory (which have icons on my system) as well as a far larger collection of document files in my Docs: directory. Normally, having extremely large directories in either case would not be a problem, but remember, you are increasing the amount of chip ram to render these icons by 50% at least. I ran into a brick wall, since I have only 1 MB of chip ram, when I attempted to open these two drawers. I had 181 files in my C: directory and watched while my chip ram dropped to 160 bytes (not kilo-bytes) whenever I opened the drawer. If you are serious about using MagicWB, you may have to break up some of your huge directories, if you have any, so that you don't drive your chip-ram into the dirt. For those that are not aware of it, there is a way to have multiple directories that are treated exactly as if the files assigned were all in the same directory. These directories are 'assigned' with multiple paths. This is a feature in 2.04+ and should be investigated if you have 75+ files in the same directory. Simply split them up and use a multiple path assign to "treat" them as one directory. Another problem that I encountered is that I have document files spread across my system as well as the usual copies in various sub-directories. Larry Phillip's Find program helped considerably in unifying the icons that I want for all doc, iff, and other format files. Find is quite capable of outputting all files that match a certain criteria to a file (using I/O redirection). It is a fairly simple matter to edit the output file into a script. You could conceivably use List with the LFormat parameter to do the same, but I found this tedious since it did not handle multiple devices easily. It was far easier to use find redirected to a file, edit that file so that it did whatever to the files, and then execute it (or source it for those of you with Csh). As a direct result of this approach, for the first time every loving document and picture on my system has the appropriate project icon! There was one problem that I ran into for which I have not established a fix. When you are updating drawers using MagicWB's script, it will not do anything with any drawer that contains a blank within the name. I did wade into the AmigaDOS 2.1 manual, but no clues as to the fix for the script were there. I don't know what to do with this problem except to ensure that I never use blanks in names again. Another problem I ran into with drawers was that some drawers were not updated by the script. The script has two problems with it, more to do with the user than the script writer. If you have a drawer that is empty, i.e. the icon is there but not the directory, the icon will not be updated. I suggest deleting them if you can. Secondly, several drawers on my system had the execute flag unset. I have no idea why the authors of the programs involved decided to set the execute flag to null for these drawers, but the plain fact of the matter is that the "Update Drawers" script will not update the icons for these drawers. I firmly suggest that you write a simple script (using List LFORMAT or a Csh or ARexx script) to update all drawers to include the "rwed" flags, otherwise you will probably have a mix of drawer icons on your system. Another suggestion. Before you even begin the installation, I highly suggest you go through each of the MagicWB drawers, select the icons, and use the unsnapshot menu-item in the WB menus. Again, this will save you wear and tear down the road when dealing with multiple icons, let alone the contents of each drawer. The last suggestion that I have is that you keep copies of the icons you think you will need to use to overwrite your current icon pictures in a readily accessible place. I'm using envarc:sys/ here, but a single drawer on your sys: disk should work better. This way when you de-archive a file, you can overwrite the icons that the programmer supplied with the MagicWB icons, appropriately tailored using the WB information menu item, for your installation. Anyway, I hope this helps some people with the installation as it is a quite radical change from the usual run of the mill icons. Brian
#109659From: Paul ToalAug 7, 1993 6:06 AM
Brian- I don't follow you in the scripts you had to run. Why did you suggest unshapshotting the stuff in the MagicWB drawers? Do it before install? Tell me more about "some type of disk reorganizer". 'preciate the info… –Paul < Motorola Inside >
#109750From: Brian BartlettAug 8, 1993 3:41 AM
Paul, if you do not have the drawers unsnapshotted, when you go to run update drawers, all the drawers will have the same exact spot encoded in the .info file that is copied. By unsnapshotting them you save yourself some hassle down the road since Workbench will dutifully note the fact and place them wherever they fit best. For most people this is not an issue. You can easily run around to every directory and do a cleanup followed by an snapshot all. I have 2,500 directories, so…<grin>. Actually, the unsnapshot should occur before you update your drawers using the provided script. You should also do the same with any default icons just as a matter of form. Furthermore, if you do use Find, or someother program, to hunt down and replace all your .info files for various project files, those should be unsnapshot before doing so. The recommendation for a disk reorganizer, especially one that will place the .info files together, is that it will speed up the rendering of the drawers whenever you open them. Rather than force workbench to look all over the hard disk for the .info files, if they are all in one small area, you speed up the opening of drawers. It can be quite a significant speedup if you have 20 or so files in one drawer. There are several good ones that I've grown to trust in the libraries as well as the commercial ones. I hope this helps. Brian
#109858From: Paul ToalAug 9, 1993 4:06 AM
Very helpful, pick a favorite disk organizer if you wouldn't mind. I probabaly saw them but didn't recognize them by file name. Thanks again… –Paul < Motorola Inside >
#110070From: Brian BartlettAug 11, 1993 2:26 AM
Paul, right now I'm using Reorg v2.31 (REORG.LHA). Reliable as heck, so far. Brian
#109678From: Harry CallesisAug 7, 1993 11:48 AM
One thing to try with the drawers that have blanks in the name: double-quote the drawer name. The script may only be seeing the first word otherwise. Harry
#109751From: Brian BartlettAug 8, 1993 3:41 AM
Harry, I know that <grin>. The problem is that the script that updates drawer icons uses List with the LFormat option to generate the commands to copy the information. Now, how do we force _it_ to generate the quotes? I'm still working on that one. The manuals, from 1.3 to 2.1 were distinctly unhelpful in that regard. I suppose I could do it manually, but I have a slight advantage using CShell to do my scripts. I want a more general fix for "the rest of us." <grin>. Brian