kdd@well.UUCP (Keith David Doyle) (10/09/86)
References: [...............] From Matt: >Solution: > In this case, it is obvious that the WorkBench ICON structure should > be modified. Specifically, it is obvious that the ICON's should all > be stored in a single file for each folder because this is what > DOS is best at... finding a known file and reading its contents. > The results: > (A) No directory searches need be done > (B) Window openning becomes an order of magnitude faster > (C) The directory/folder structure is retained > (D) The fix can be propogated without invalidating any software to date by the simple distribution of a new workbench and a utility to convert from the old (multiple files) to the new. > It does not make sense to modify DOS: > (A) Directory searches for most applications are now almost completely > eliminated so modifing DOS may become superfluous. > (B) Applications now have a new way of finding specific information > (like DPAINT files) by having that information be represented > by N ICONS (all of which can be accessed almost instantaniously). > (C) Changing DOS would break everything in existance that does funny > things with the disks, and probably more. > -Matt I hate to open up a can of worms here, but there ARE a few other reasons to consider modifying DOS: (A) Directory searches for CLI based programs will also be enhanced. I came up through the CPM days, and DIR could fill the screen with file names in a couple of seconds (from a floppy). Not so with the Amiga. I find myself doing a Ctrl-C to directory lists often enough, because I don't want to wait for the entire search through the whole directory. (B) Applications that DON'T USE the workbench, and don't need disk space being gobbled up with redundant directory information, may still be slow if they have to do complete directory searches when they put up filename requesters. At least unless ALL FILES have associated icons. I have noticed a few smarter utilities lately (notably SoundScape) that read the directory once the first time you invoke such a requester, and keeps the list around in memory so it dosen't have to re-search if you go back to the requester a second time. Changing the drive selection will still bite you though. (C) Either the programs, or via some modification of DOS are going to need to keep the icon/info file updated as programs write files. Not all programs create icons for everything that is written out. (D) And, remember that the Mac will re-use the same bit image for a particular icon, though the Amiga has a seperate copy of the bit image for various icons. THis is a *feature* of the Amiga you'd kind of like to keep, as you would like to have the ability to make every icon look different possibly, though a disk full of identical DPaint brush icons is not particularly attractive. It's a tradeoff. Not that I'm particularly arguing for modifying DOS. But since I very RARELY use the workbench over the CLI, I kinda hate to see a lot of effort put into speeding up the icon display while leaving CLI directory searches the way they are. Granted, one of the reasons I may not be using the Workbench much may be BECAUSE it is a bit slow, I'd just like to get a speed increase for BOTH mechanisms if possible. Either way or neither way, I'm probably going to go with the flow, as I can't really see myself hacking on DOS or the Workbench much, I'd rather be working on applications. Just had a few more points to throw into the hat. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa "TOO MUCH is better than NOT ENOUGH"
u-jmolse@utah-ug.UUCP@utah-cs.UUCP (John M. Olsen) (10/10/86)
--> Aim positronic ray gun here <--
I thought I would throw a comment into the discussion on WorkBench
and DOS modifications. It may not cure all the ills in the system, but
wouldn't the icon access go up dramatically if there were simply an extra
file containing the names of all the icons in a directory? This also seems
like a reasonably small modification to the WorkBench.
John M. Olsen
u-jmolse%utah-ug@utah-cs.arpa
...!{seismo,ut-sally,bellcore,cbosgd,ulysses,ihnp4}!utah-cs!utah-ug!u-jmolseacs@amdahl.UUCP (Tony Sumrall) (10/12/86)
In article <1903@well.UUCP> kdd@well.UUCP (Keith David Doyle) writes: > (B) ... > ... I have noticed > a few smarter utilities lately (notably SoundScape) that read > the directory once the first time you invoke such a requester, and > keeps the list around in memory so it dosen't have to re-search > if you go back to the requester a second time. Changing the > drive selection will still bite you though. Couldn't this cause problems? I mean, given the fact that my Amiga is a multi-tasker, I create a file which *should* be picked up for display by the filename requester but *won't* be picked up because the program thinks that it already knows what's out on the disk? > > Keith Doyle -- Tony Sumrall ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/12/86)
>> (B) ... >> ... I have noticed >> a few smarter utilities lately (notably SoundScape) that read >> the directory once the first time you invoke such a requester, and >> keeps the list around in memory so it dosen't have to re-search >> if you go back to the requester a second time. Changing the >> drive selection will still bite you though. > >Couldn't this cause problems? I mean, given the fact that my Amiga is a >multi-tasker, I create a file which *should* be picked up for display by >the filename requester but *won't* be picked up because the program thinks >that it already knows what's out on the disk? No problem... When you create a file, the timestamp for it's diretory is updated. All the program needs to do is look at the timestamp, and if it has changed, reload the directory. Only the timestamp for the immediate directory (directory containing the file) is updated.. the changes are not propogated through the path. Don't you love simple solutions? -Matt
cc1@locus.ucla.edu (Michael Gersten) (10/14/86)
There is a file with the names of icons alReady; it is ignored if the directory
has been modified, however.
The problems are:
fastdir changes the directory when it writes out its file (even if .dir
existed before; is this a bug?)
PutDiskObj() does not seem to update the .info file, so WB has to take
another look at the entire directory
The list is not sorted by directory access (would be rather hard to do),
so it may make it worse by switching tracks more often (how about doing
multiple track buffers at the trackdisk.device level C-A? Just 2?)
Views expressed here may not be those of the Computer Club, UCLA, or
anyone in their left OR right mind. And that's the name o' that tune.dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/14/86)
>so it may make it worse by switching tracks more often (how about doing >multiple track buffers at the trackdisk.device level C-A? Just 2?) You actually need 4 to get *really* good improvment (remember, each cylinder has two sides and thus two tracks). -Matt
hamilton@uiucuxc.CSO.UIUC.EDU (10/15/86)
acs@amdahl.UUCP (tony sumrall) says: > In article <1903@well.UUCP> kdd@well.UUCP (Keith David Doyle) writes: > > (B) ... > > ... I have noticed > > a few smarter utilities lately (notably SoundScape) that read > > the directory once the first time you invoke such a requester, and > > keeps the list around in memory so it dosen't have to re-search > > if you go back to the requester a second time. Changing the > > drive selection will still bite you though. > > Couldn't this cause problems? I mean, given the fact that my Amiga is a > multi-tasker, I create a file which *should* be picked up for display by > the filename requester but *won't* be picked up because the program thinks > that it already knows what's out on the disk? exactly. i have written a self-contained file requester function based on charlie heath's getfil.o. i was very tempted to add that caching feature, but finally decided against it. you don't have to invoke multi-tasking either; one of the reasons for a file requester is the creation of new files. changing the drive selection is not a problem. my requester routine takes a "current" directory name as an argument, so it can easily tell if a new drive/directory is involved. more serious is the possibilty that the user has swapped disks since the last invocation, but there are probably easy ways to detect this. now, if we had modification datestamps on directories, and file creation or deletion resulted in an update... wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton