home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / misc / b138_1 / !Mycop / !Help next >
Text File  |  1993-11-19  |  7KB  |  173 lines
  1.  
  2. another one in the series 'going into the 2nd dimension'
  3.  
  4. !Mycop is a Mülleimer which is a bin
  5.  
  6. it works like many other trashcans: to 'delete' an object drop it onto
  7. the bin. if it's nice the object will be stored away in !Mycop.Bin
  8. if it's not nice you must be knowing what you're doing
  9.  
  10. (now that i've come to think about it: only !Trash by Richard K.Lloyd
  11. is configurable this way, other bins seem to be nice only)
  12.  
  13. bin's current niceness is reflected by the LED in the upper right corner
  14. of the icon: when the LED is red, the bin is deadly
  15. (at least this is so with my sprites ...)
  16. also, when you click SELECT on it to start a bulk delete you can tell
  17. straight away whether it's nice or less
  18.  
  19. you can see if a nice bin is not empty
  20. a deadly bin is always empty, so when you make a non-empty nice bin
  21. deadly (see below) the icon changes also
  22.  
  23. unlike all the other bins !Mycop has no iconbar icon but sits on the screen
  24. where you've put it. you move it around with the ADJUST button since
  25. SELECT is used for:
  26.  
  27. 1) bulk deletes
  28.    if you want to get rid of everything in a filer window, you can
  29.    'select all' from filer's menu and drag the selection to the bin.
  30.    easier and faster: click SELECT over the bin - the pointer changes
  31.    into a thing that'll reflect current bin state. drag the thing to your
  32.    window and release the button
  33.  
  34. 2) opening !Mycop.Bin
  35.    hold down ⇧Shift and click SELECT over the bin - if the bin's nice
  36.    the directory things are stored away in opens up. nothing will happen
  37.    if the bin is not nice
  38.  
  39. to move !Mycop around in its current position in the windows stack
  40. you drag it with ADJUST held down. if you want to bring it to the top of
  41. the stack hold down Ctrl while ADJUSTing. it goes to the bottom instead
  42. if you're ⇧Shift+ADJUSTing. a crib: left hand Ctrl is on top of ⇧Shift
  43.  
  44. clicking ADJUST changes the pointer to a hand. if you just want to bring
  45. a partially obscured bin to the top but not move it otherwise, move the
  46. pointer away from it to restore the default pointer. MENUing will also
  47. restore the default pointer
  48.  
  49. the 'main' menu:
  50.  
  51.  Mycop
  52. -------
  53. Info  ⇨
  54. Empty           empties the bin if there's something in it
  55. State ⇨
  56. Quit
  57.  
  58. Empty will be grey if the bin is empty or not nice
  59.  
  60. the State submenu:
  61.  
  62.    State
  63. ----------
  64. Nice bin        will be €ed if the bin's nice
  65. Delete   ⇨
  66. Save            saves current state
  67.  
  68. the state of the bin comprises its niceness, position on screen and
  69. the settings of the 'Delete' submenu. the state is saved in !Mycop.State
  70. if this does not exist, a nice bin keen on @ and open files (see below)
  71. is placed somewhere on the screen on startup (btw why would a sane woman
  72. need > 1 bin on his desktop?)
  73.  
  74.   Delete
  75. -----------
  76. Current Dir
  77. Current Lib
  78. Open files
  79.  
  80. '€ Current Dir' means: if one of the objects the bin is considering to bin
  81. is the Currently Selected Directory (@) on that object's filing system,
  82. don't give the 'Can't delete current directory' error but kill the object
  83. gracefully
  84.  
  85. '€ Current Lib' : above, replace CSD by 'Currently Selected Library' (%)
  86.  
  87. '€ Open files' : similar for open files
  88.  
  89. if you unset an option you don't get the default filer error box back,
  90. the object in question just won't be deleted
  91.  
  92. inconsistencies
  93. ===============
  94. there are 2 of them
  95. they're a consequence of the way the binning process is implemented and
  96. crop up only when the bin is nice and you're binning a directory with an
  97. open file in it
  98.  
  99. some remarks about how the binning process is implemented
  100. :
  101. when you drop a selection onto !Mycop it appears to me as if i'm dealing
  102. with just ONE object so it's easy to find out whether it's a dir, a file,
  103. the @ or the %
  104. :
  105. when you go the other way i get a SET (directory) of objects each of which
  106. must be isolated for 'comparing' with the options
  107. :
  108. so, if necessary, i do a ONE LEVEL scan first
  109. :
  110. now, if the object that's going to be binned is on the same filing system
  111. as the !Mycop application directory then it (the object) will be RENAMEd
  112. into !Mycop.Bin.object; if it's on a different FS it will be recursively
  113. COPYed and the original'll be destroyed
  114. --
  115.  
  116. (reminder: we're talking about nicely binning an object
  117.            there aren't any inconsistencies when the bin is not nice)
  118.  
  119. inconsistency #1
  120. ----------------
  121. !Mycop detects open files by intercepting the 'file open' error which
  122. does NOT work when RENAMEing a directory with an open file in it - this
  123. slips through and you don't get the error. So you can end up with a
  124. directory being 'deleted' inspite it contained an open file and the
  125. 'Delete.Open files' option was NOT set
  126.  
  127. inconsistency #2
  128. ----------------
  129. the second inconsistency manifests itself when ObjectFS <> MycopFS and
  130. again you do NOT want to 'Delete.Open files' but are binning a directory
  131. with an open file in it. !Mycop identified the directory as the object
  132. to act upon and executes a COPY ... rfd on it. Some way through the dir COPY
  133. detects an open file an exits with the 'file open' error and the file is
  134. let alone. You'd say, 'well, that's exactly what i wanted' but if the
  135. directory contains objects 'behind' that open file they won't be deleted
  136.  
  137. this is a bit annoying but removing it would mean to search a directory
  138. TREE for open files - i thought it's not worth it (not what you think,
  139. i LOVE recursion, but it would slow the whole thing unnecessarily down)
  140.  
  141. besides, the reason i wrote !Mycop was that all the bins i know about
  142. don't let you delete the @, the % or an open file, requiring you to quit
  143. the error box, to go to the command line and to say NoDir, NoLib or Close,
  144. possibly preceding each with the -RelevantFS-
  145.  
  146. so to me the above 'inconsistency examples' are purely academic -
  147. i have all three Delete options set and saved
  148.  
  149. apropos save: don't forget that when you save a state, the current position
  150. of !Mycop on the screen is saved as well, so the next time you run it
  151. it appears where it was when you clicked on Mycop:State.Save the last time
  152.  
  153. finally, !Mycop recognizes attempts to kill a directory containing
  154. a directory ... containing a directory containing !Mycop itself,
  155. any objects inside it and any objects inside !Mycop.Bin and reacts
  156. harsh - it does nothing.
  157.  
  158. finallyfinally: !Mycop starts the animation before it's sure that at least
  159. one object is going to be deleted. So, if you feed it a @ but the
  160. 'Delete.Current Dir' option is unset, the animation could fool you of
  161. something being deleted ... I had this working ok but i couldn't stand
  162. the sight of 1000 IF's
  163.  
  164. last but not least: i borrowed (only big artists steal) the code to monitor
  165. 'any directory-changing activity' from Richard K.Lloyd's !Trash
  166. i couldn't have done it myself anyway because Arthur does know nothing about
  167. the UpCall 3
  168.  
  169. franz philipps
  170.  
  171. ehrm !Mycop was written on a 4mb machine so 32k is the smallest possible
  172.      WimpSlot but you'd surely get along with less
  173.