dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/30/87)
>But but but but....we have to admit that the drawer opening speed MUST BE >IMPROVED ! I'm not too hot on the idea in the first posting, since the >thing must still muck around in multiple files. Let's get this straight: >(I know I'm right :-) ) the icons must be cached together to get decent >performance. If they're still split up the drawer opening time will still >be dismal. I really am not too concerned with the possibility that doing >the internal combination of icons might make that *part* of the guts of >my Amiga OS look *slightly* mac like. Heck, we both use icons and windows, No ? >Except we have the "advantage" of slow drawer opening.....gosh.... :-). >If there's one improvement that need to be in 1.3, that's the one ! Making an icon oriented interface supported at the filesystem level is simply not feasible... it doesn't solve anything, and makes for big compatibility problems (like files are no longer simply files). The *proper* way to do it simply to stick all the icons for a given directory in a single file. Since the directory is hash based, this eliminates directory searches completely, and allows any optimization in filesystem performance to be automatically reflected in the speed at which icons come up. Bringing up ALL the icons in a window is as easy as reading, say, a 4K file. If a window had, say, about 20 icons in it, you're talking about a 6K file. How long does it take to load a 6K file from a floppy???? about a second. Q.E.D. The solution is staring us all in the face. -Matt
gary@mit-eddie.UUCP (04/30/87)
In article <8704292134.AA22507@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Making an icon oriented interface supported at the filesystem level >is simply not feasible... it doesn't solve anything, and makes for big >compatibility problems (like files are no longer simply files). As you say, Matt, NO NO NO NO NO! Today, files are not simply files. Files are TWO files! Solving this problem at the filesystem level (or at least at DOS level) is the most appropriate way. You forget about us, the developers writing software that must deal with these icon files as well as the actual file each time we delete, create, move, or copy one. In fact, I have a s**tload of extra code to deal with a user's preference for Workbench style or CLI style file handling (if he chooses Workbench style, icon files are created when necessary; }iif he chooses CLI style, they are not). It makes MUCH more sense for the user to choose a Preference at the system level to handle this difference and let the filesystem do the rest of the work. Gary
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/02/87)
In article <5668@eddie.MIT.EDU> gary@eddie.MIT.EDU (Gary Samad) writes: >In article <8704292134.AA22507@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> Making an icon oriented interface supported at the filesystem level >>is simply not feasible... it doesn't solve anything, and makes for big >>compatibility problems (like files are no longer simply files). > >As you say, Matt, NO NO NO NO NO! > >Today, files are not simply files. Files are TWO files! > >Solving this problem at the filesystem level (or at least at DOS level) >is the most appropriate way. [ ... ] > >It makes MUCH more sense for the user to choose a Preference at the system >level to handle this difference and let the filesystem do the rest of the >work. > > Gary (NO!) ^ 37. Believe it or not, files *are* files. What you perceive to be schizophrenia is in fact the result of a design consideration for Workbench. Workbench could easily have been written to simply scan the entire directory and display a standard icon for each and every file. Perhaps it might have also wanted to tickle some unused longword fields in the file header to determine what type it was, so it could decide which of the standard icons to draw. Yes indeed. Workbench could have been made to look just like GEM (doesn't that make you want to sing and shout?). As it is, we have a bit more flexibility in telling Workbench what our icons look like. We can selectively make icons disappear without destroying the program they point to. We can define *any* icon image. I think what you want is the illusion of invisibility. UNIX systems have a form of this invisibility already. It's called the "dot" file. Any filename beginning with a "." is not displayed when you ask for a directory, unless you explicitly ask for it. I imagine this was installed when people such as yourself long ago complained that they got sick of seeing all their .login, .logout, .profile, and .*rc files all the time. So. All you have to do is write a 'dir' program that, while collecting filenames, checks to see if the last five chars are ".info". If so, you ignore it and go on to the next one. Thus, all your .info files magically become invisible. One of the beautiful things about the Amiga is that there's always some way to do what you want. You want your .info files to be invisible. You could hack the filesystem to pieces. You could re-write the DOS (Oh, Please!). You could re-write Workbench. Or you could write a new 'dir' program that lets you fake invisibility. I guess this argument comes from the fact that we can choose our user interface. The Mac provides no such choice, and as far as the user is concerned, it very well *could* be manipulating two files around when he drags an icon (no corrective flames, please; this is an illustrative point). Sidenote: The filesystem has already been hacked once to accomodate the Workbench. The block allocation algorithm was slightly perverted to put the first data block of a file as close to the file header block as possible, to save on disk grinding when putting up icons. Check out the disk layout with my file mapping program, 'fm' sometime. Once again, this is just me talking..... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun.H.