mikhe@majestix.ida.liu.se (Mike Henry) (05/02/90)
In article <18023@snow-white.udel.EDU> kosma%human-torch@stc.lockheed.com (Monty Kosma) writes: >In article <17896@snow-white.udel.EDU>, BARRETT@owl.ecil.iastate.edu (Marc Barrett) says: >> >>It is simply nice to have a single, system trashcan rather than a >>seperate trashcan directory on every disk. >> >>I agree. And since Commodore has done it, how hard would it be to create So do I. >>such a Trashcan? One approach would be to put some code in >>the mouse event chain that watches for icons being released over the >>new trashcan, and then deletes that object. Of course, I don't really ^^^^^^^^^^^^^^^^^^^ B^( Not, really... >> >>So. How could one add a Mac/NeXT like disposal unit?? >> >> lee ... >Basically, all of the "free floating" sorts of icons currently at >least are disk drives, so why not just make an extra ram disk called ... ^^^^^^^^^^^^^^ B^( >it's better not to have the trashcan use ram for all its stuff, so I Yeah !! B^) >guess we just need to make a link from there to some directory on yer >hard disk or somewhere more appropriate :-] No, (yet another B^) handler should be used, in my mind, to move the file to the Trashcan directory on the disk the file is on. That way you always know you have the space to keep the file and it won't waste RAM. You would only need one Trashcan Icon on the WB and the handler would take care of the moveing of the "deleted" files. The Trashcan, when opened, would contain the deleted files (as usual) and when you move your file out again, either back to its origin or to another disk, it would be removed from the Trashcan (and the disk where it resided originally, if necessary). There would be no intermediary file saving and no need to change anything else than a reference to a file in a dirctory block on the disk it resides. When "The User" chooses the "Empty Trashcan" menu item all files on all disks that reside in the Trashcan will be physically removed. If no Trashcan exists on a disk it is created by the Handler when a file is dropped in the Trashcan, for those of us not useing this method of deleteing our files no Trashcan directory will reside on our disks (and is not necessary). Alternatively, a file "residing in the Trashcan" could be marked with a flag as being such. At (REAL) deletion time all disks are scanned and those marked for deletion are physically removed. The only thing we save here is the presence of the Trashcan directory on each disk, we lose time scanning for files to be deleted, though. I guess with my $0.02 we're up to $0.04, and counting... B^) >monty -Mike -- INET : mikhe@ida.liu.se /// UUCP : {mcvax,munnari,ukc,unido}!enea!liuida!majestix!mikhe /// ARPA : mikhe%majestix.{ida.liu.se,UUCP}@seismo.CSS.GOV \\\/// What SNAIL: Mike Henry, Alsattersg. 3C:20, S-582 51 Linkoping SWEDEN \XX/ Else??
FelineGrace@cup.portal.com (Dana B Bourgeois) (05/03/90)
Concerning the 'single' trashcan on workbench under discussion... ...what kind of behavior should be exhibited when a file protected from deletion is dropped on the trashcan? I say the file should be moved into the trashcan directory as if it were not protected but it's protection bit should be preserved so empty trash cannot empty it. It should be moveable out of the trashcan also if grabbed as an icon. In other words, move files into and out of trashcan despite the protection bits if grabbed as an icon but preserve the protection bits. Don't allow the move if tried from the CLI if 'undeleteable' is set, however. Dana Bourgeois @ cup.portal.com 'course I could be wrong...