Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ll-xn!mit-eddie!bbn!rochester!cornell!batcomputer!cloos From: cloos@batcomputer.tn.cornell.edu (James H. Cloos Jr.) Newsgroups: comp.sys.mac Subject: Re: 'Virtual' Folders - good idea!! (This reply 100 lines) Message-ID: <5282@batcomputer.tn.cornell.edu> Date: 24 Jun 88 07:28:53 GMT References: <46100167@uxe.cso.uiuc.edu> <1437@spar.SPAR.SLB.COM> Reply-To: cloos@tcgould.tn.cornell.edu (James H. Cloos Jr.) Organization: Cornell Computer Services, Cornell University, Ithaca, NY 14853 Lines: 96 In article <1437@spar.SPAR.SLB.COM> freeman@spar.UUCP (Jay Freeman) writes: >In article <46100167@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes: > >> then let "virtual folders" have an entirely different characterization >> in the desktop paradigm. For example, you might characterize a >> "virtual folder" as a sheaf of documents held together by a paperclip. > >I think that's a useful idea. How about a simple implementation as a >display hack: Suppose it worked that whenever I positioned two icons so >that they overlapped, the finder noticed it and instead of displaying two >overlapping icons it displayed just one icon, a sheaf of documents held >together by a paperclip. One could presumably then grab that icon and move >all the documents as one; indeed, almost any selection of that icon would be >immediately interpretable as a selection of all the clipped-together >documents. Exception: I think I would like all the special commands that >reorganize the desktop to continue to preserve clipped-together documents, >and I would like an additional menu command to spread apart the documents in >a (selected) clipped-together sheaf. Maybe there should also be a way to >peel the top document off a sheaf, like using a modifier key when mousing on >it. > > If it were done this way, then there would be no need for a special, >"make-virtual-folder" command; you'd make a pile of things by putting one >thing on top of another, just as we all do with real desktops. (Surely >a computer interface for the rest of us should preserve the paradigms >whereby we create and manipulate messes.) And at a slightly lower level, >the finder info data structure for a file would not need to be changed; >it already contains position information and that's all the finder would >need to determine whether to display individual icons or clipped-together >bunches. > > I think I would want this hack to work with full-sized or miniature >icons, but I think I would like the displays of documents by name, kind, >date and so forth to list all documents in a folder, whether or not they >were clipped together. > > -- Jay Freeman > >This is by far the best suggestion yet on this topic. The idea to simply alter the system routines to have them look in specific sub-folders w/in the System folder when searching for inits, cdevs, etc. is desireable, and I hope it gets included in the next system release. Jay's proposal, however, is much more useful, and can be applied to many more situations. Further, the implementation would seem to be an order of magnitude easier. In addition to displaying the paper-clipped icon (PCI) whenever two icons are manually overlapped, I would like to see a new entry in the Special menu. This entry is active whenever either multiple icons or a PCI is selected. If a single PCI is selected, the entry would read something like 'Expand Selection' and when selected, would separate all of the icons in the stack a la 'Cleanup Selection' does when a stack of icons are selected. If multiple icons are selected, the entry would read something like 'Collect' and when selected, would stack all of the selected icons, creating a new PCI. The placement of the new PCI would be dependent on what kinds of files were selected. The 1st choice is the top left PCI if any current PCI's are selected. The 2nd choice is the top left normal icon if no PCI's were selected. Whenever a single normal icon or no icons are selected, the entry would be a greyed-out version of the 'Collect' option. The changes to the finder are, in addition to manipulating the new menu entry discussed above, that clicking on a stack of icons now would default to selecting them all. Clicking while depressing the command and/or option key(s) [nb: for simplification in writing, I'll assume below that the option key is the modifier, but any of the 3 choices could be chosen] would chose only the top icon, and then (maybe) scroll thru the other icons in the stack. (Comments on this appreciated, as it might be non-intuitive re: double opt-click would not open the application/document.) Also (the only sticky point I can see) a change would likely be required re: the text displayed w/ the icon. Do you name it, say, PCIn (where n is an unique integer), or still show the name of the top icon plastered over those below it, or let the user give the PCI its own unique name, or sPCi (where s is a string containing a concat of the document types; eg. if cdevs are known as 'Control Panel Device's and inits are known as 'Init Document's then a PCI w/ cdevs and inits is called 'Control Panel Device/Init Document PCI'), or what? I can think of arguments for each of these, but tend to lean toward maintaining the current method. There are manu uses for this feature, and it would seem rather easy to implement in the Finder. I would hope that Apple gives some serious thought to implementing it--and failing that does anyone else out there want to write an application that alters the Finder to add this feature? -JimC -- batcomputer!cloos@cornell.UUCP |James H. Cloos, Jr.|#include cloos@batcomputer.tn.cornell.EDU|B7 Upson, Cornell U|#include cloos@tcgould.tn.cornell.EDU |Ithaca, NY 14853 |"Entropy isn't what cloos@crnlthry.BITNET | +1 607 272 4519 | it used to be."