hadeishi@husc7.UUCP (04/17/87)
Keywords: In Re-hash: I proposed a addition to the standard Workbench icon, the "attached-files" icon, which would basically be a single icon which could refer to multiple files, even directories of files. Attached files could be copied, copied into the :s, :l, :devs, etc. directories of the target devices, or copied and appended to specific files (i.e., devs/Mountlist). Design objective is to allow Workbench users to manipulate libraries, etc., giving more control over the Workbench environment without cluttering up the desktop with thousands of confusing little icons of all the .library, .device, and so on files. (Alternative design would be to make Workbench display a default icon for all of the non-iconized files in all directories, of course switchable with a menu item. This would be confusing for the non-CLI user, etc . . .) A possible glitch with my attached-files icon scheme for Workbench is the following: someone may create a library shared by several applications, but a data directory used by only one application. You'd have to be careful not to have more than one icon have an overlapping set of attached files; if you did this, then if the user deleted one of the icons, the attached files for that icon would go away, but the other icon would still be there, and yet the application related to that icon would not work. This is Not Good. Users would go mad, get angry, arrrgh . . . Anyway, the solution is simply to tell designers to only group together support files to be referenced by a multiple-file icon if they ALWAYS GO TOGETHER. That is, no one could possibly want to use just SOME of those files, and not others (i.e., no one would EVER want to create an attached-files icon that intersected with that icon's attached-files icon, unless the intersection was set equality.) -Mitsu
flaps@utcsri.UUCP (04/19/87)
In article <1685@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes:
:>In Re-hash: I proposed a addition to the standard Workbench icon,
:> the "attached-files" icon, which would basically be a single icon
:> which could refer to multiple files, even directories of files.
:>A possible glitch with my attached-files icon scheme for Workbench
:>is the following: someone may create a library shared by several
:>applications, but a data directory used by only one application.
:>You'd have to be careful not to have more than one icon have
:>an overlapping set of attached files; if you did this, then if
:>the user deleted one of the icons, the attached files for that icon
:>would go away, but the other icon would still be there, and yet
:>the application related to that icon would not work. This is Not Good.
:>Users would go mad, get angry, arrrgh . . . Anyway, the solution
:>is simply to tell designers to only group together support files
:>to be referenced by a multiple-file icon if they ALWAYS GO TOGETHER.
Why not simply have a reference count? Store in the file header something
saying "I am attached to x attached-files-icons." Then when you delete
an attached-files-icon, decrement all reference counts & delete only the
files which hit 0.
Of course then your application would have to respect the file headers.
This would preclude using some existing applications, but I think that
this would work well with new applications designed for use with this
mechanism. Old applications would just have to use your solution above.
--
Alan J Rosenthal
flaps@csri.toronto.edu, {seismo!utai or utzoo}!utcsri!flaps,
flaps@toronto on csnet, flaps at utorgpu on bitnet.
"Probably the best operating system in the world is the [operating system]
made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977