blm@cxsea.UUCP (Brian Matthews) (06/22/88)
Larry Rosenstein (lsr@apple.apple.com) writes: |In article <3818@saturn.ucsc.edu> gagaku@ucscd.UCSC.EDU (PUT YOUR NAME HERE) writes: |>Since my original posting of this idea, I've seen a bunch of follow-ups |>generally enthusiastic, but nothing from programmers or Apple folks as |>to whether the concept is even feasible within the structure of the Mac |>System. Any ideas on this? |The idea of "virtual folders" technicay possible, since it is done on MFS |systems. I don't think it would be such a good idea from the user interface |point of view. One would end up with 2 ways of organizing files that have |subtle differences. Even if you make the virtual folder icons look |different, the concepts would still be the same (a way to categorize files). | |For example, one problem is the proliferation of cdevs, INIT, etc. in the |System folder. As was pointed out, it would be simpler and cleaner to |modify the System to search for these things in a subfolder. If this change |would solve 90% of the problems, then it would make more sense than adding |virtual folders and their possible complexity. I agree completely. I think virtual folders would increase the complexity of the system and the user interface a lot, compared with little gain. I've always considered it a problem that so much junk has to be stuck in the top of the system folder, but the fix I'd like to see is for INIT 31 and Control Panel to look in all subdirectories also. I've dug around in INIT 31 for just this reason, and although I haven't made any changes, it looks like it would be relatively simple for INIT 31 to search directories (and directories in directories (and directories in directories in directories (and ... :-) ))). -- Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises
alexis@dasys1.UUCP (Alexis Rosen) (06/24/88)
ine eater still exist?] The concept of the path is an elegant solution to the generic problem of how to store and categorize files. In the Mac's case, it needs only one or two alterations to really provide an intuitive, useful, and *COMPATIBLE* solution to the problem that you, I, and everyone's uncle Harry is having with organizing files on your typical average 780 MB disk... First, the poor man's search path (the System Folder) must remain in some form in order to provide compatibility with current systems. This doesn't limit our options at all; just keep the System Folder as the first directory in the search path. Furthermore, there should be two options available through the control panel: 1) Always keep all subdirectories of the System File in the Search Path 2) Move the System File to the back of the Path instead of the Front The first option is powerful and important; the second could be dispensed with if Apple deemed it to confusing (it's not, but who knows about their H.I.G.?) There is one possible extension of the File System which would make this a much more powerful solution: Along with the "Blessed Folder", we get the "Configur- ation Folder". It is a folder that is set to the System Folder at first bootup, for the sake of novice users, but can be pointed anywhere (including a subdirectory of the System Folder, which is probably where I'd put it.) It would be provided to applications at their request, so it would be transparent to applications without knowledge of this feature. This extension provides 100% compatibility with current programs and wimpy-users (excuse me... novices :-) without sacrificing any elegance or power. It can be set along with the two options mentioned above in one control panel device. (Now those CDEVs were a damn good idea!!) I would like to point out that a "Configuration Folder" is especially useful in a multi-user environment. If we ever get to the point where we want many people booting out of the same System Folder (I think we will), it will be an absolute necessity. One thing I haven't seen discussed is the actual meaning of the word "Path". In MS-DOS (yuck) the Path is only used to search for executables (and batch files). Dos 3.10 and higher provide a command called 'Append' which is really a path for all types of files. In the Mac's File System, DOS's concept of PATH doesn't make a whole lot of sense, since 98% of the time the need for finding executables is while using the finder, which has something better than a path: the Desktop File (that's assuming that Apple fixes it, as they did with the Desktop Manager INIT under AppleShare). Therefore I feel strongly that any provision for a path setting should work for all types of files. I agree totally with Larry Rosenstein's statement that two types of folders would be a real mess. Highly counterintuitive, even to the non-wimps! The last thing we should do is perpetuate the disaster that was MFS. (This is not a criticism of the designers of MFS, but hindsight provides a powerful indictment of that flat file system- or any flat file system, for that matter). /Alexis p.s. Maybe the configuration folder should be called the "Preferences Folder", in deference to all the programs which call their settings options "Preferences". Makes for a _Standard_ User Interface. (Note the caps :-) /a -- Alexis Rosen {allegra,philabs,cmcl2}!phri\ Writing from {bellcore,harpo,cmcl2}!cucard!dasys1!alexis The Big Electric Cat {portal,well,sun}!hoptoad/ Public UNIX if mail fails: ...cmcl2!cucard!cunixc!abr1
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (06/25/88)
In article <5151@dasys1.UUCP> alexis@dasys1.UUCP (Alexis Rosen) writes: >The concept of the path is an elegant solution to the generic problem of how to >store and categorize files. In the Mac's case, it needs only one or two >alterations to really provide an intuitive, useful, and *COMPATIBLE* solution >to the problem that you, I, and everyone's uncle Harry is having with organizing >files on your typical average 780 MB disk... I should point out that the minimum allocation unit on your uncle's disk is 12288 bytes. I submit that this won't be a real problem until Apple's file system can handle more than 65K allocation units per volume. Marc Kaufman (kaufman@polya.stanford.edu)