armhold@topaz.rutgers.edu (George Armhold) (02/11/89)
I'd like to see a menu item in Workbench 1.4 that lets you remove old disk icons from the screen after you're done with them. I'm usually stuck with a few lying around, cluttering up my screen even after the disks have been removed from the drives a long time ago. (Just a thought...) -GEA
mp1u+@andrew.cmu.edu (Michael Portuesi) (02/13/89)
armhold@topaz.rutgers.edu (George Armhold) writes: > I'd like to see a menu item in Workbench 1.4 that lets you remove old > disk icons from the screen after you're done with them. I'm usually > stuck with a few lying around, cluttering up my screen even after the > disks have been removed from the drives a long time ago. Workbench already removes disk icons when the system is done with them. AmigaDOS has the concept of a "lock" on a file. When you have made a directory current with CD, for example, a lock is placed on that directory. If you remove the disk that you have CD'ed to, it's icon will remain on the display. If you run a program that accesses files on a particular disk, the icon for that disk will remain on the display whether or not the disk is in the drive, because your application has locks on files on that disk. What this all boils down to is that even though *you* may done with the disk, the system may not. The icons for disks that the system is done with will go away. If there is still a reason for that disk to be needed again, the icon will not go away. Sometimes poorly written programs will not release locks on files they access. In that case, you can wind up with icons on your workbench display even though there are no programs around using files off that disk. There are programs around that can remove locks on files, mostly to deal with these poorly-written programs, but they should be used carefully. You don't want to wipe out a legitimate file lock. --M -- Michael Portuesi / Information Technology Center / Carnegie Mellon University INET: mp1u+@andrew.cmu.edu / BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ "I'm very sorry, Master, but that WAS the backup system" -- Slave
jesup@cbmvax.UUCP (Randell Jesup) (02/14/89)
In article <Feb.10.16.47.28.1989.11449@topaz.rutgers.edu> armhold@topaz.rutgers.edu (George Armhold) writes: >I'd like to see a menu item in Workbench 1.4 that lets you remove old >disk icons from the screen after you're done with them. I'm usually >stuck with a few lying around, cluttering up my screen even after the >disks have been removed from the drives a long time ago. They do go away. However, if you have a lock on them (cd'ed into the disk, in your path, and assign to the disk, or a program that leaves locks hanging (and loses 24 bytes per run)), then they will remain. Try sticking a disk in, opening it, close it, and remove the disk. The icon will go away after a couple of seconds. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
dooley@helios.toronto.edu (Kevin Dooley) (02/14/89)
In article <Feb.10.16.47.28.1989.11449@topaz.rutgers.edu> armhold@topaz.rutgers.edu (George Armhold) writes: > >I'd like to see a menu item in Workbench 1.4 that lets you remove old >disk icons from the screen after you're done with them. I'm usually >stuck with a few lying around, cluttering up my screen even after the >disks have been removed from the drives a long time ago. >(Just a thought...) > > -GEA This sounds like a very bad idea to me. If you're really done with the disk, the icon does automatically disappear. If it doesn't go away, then there is still some process which has dependancies on that disk. It could mean that some file or directory was locked and never unlocked. It could mean that there are ASSIGNments to that disk. In any case, if an icon does not disappear when the disk is removed, it is either still needed or there a some buggy code around. -- Kevin Dooley UUCP - {uunet,pyramid}!utai!helios.physics!dooley Physics Dept. BITNET - dooley@utorphys U. of Toronto INTERNET - dooley@helios.physics.utoronto.ca
hrc@himalia.dk (Henrik Raeder Clausen) (02/14/89)
I'd like in 1.4 to have the System Requesters tell the user what file
some program is looking for (like devs:disk-validator). This would be a
great help for the average users, especially the ones with only one floppy,
into building bootable disks that contain exactly the things they need.
I actually got this idea from a PC user with Amigoid friends, who was trying
to install some programs. I can't belive it's hard to do.
Yours, Henrik Clausen, hrc@daimi.dkc152-cb@cory.Berkeley.EDU (Vince Lee) (02/22/89)
In article <1984@daimi.dk> hrc@daimi.dk (Henrik Raeder Clausen) writes: >I'd like in 1.4 to have the System Requesters tell the user what file >some program is looking for (like devs:disk-validator). This would be a This really doesn't make any sense. It's really the program's responsibility to inform you what files it can't find. Some programs check for files in several locations. It would be REAL annoying to get a requester every time you mistype a command and your shell program searches thru its whole path for "Assing." The requesters that come up for "insert volume XXX" are different b/c the amiga is multitasking and lets you change disks whenever you want. I think more programmers would be willing to put error messages in their programs if there were a simple ShowMessage(window,string) command included in K/S. This isn't a lot of code, but for small programs, setting up Intuitext structures is too annoying.
carlson@betelgeuse (Richard L. Carlson) (02/22/89)
In article <10196@pasteur.Berkeley.EDU> c152-cb@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >In article <1984@daimi.dk> hrc@daimi.dk (Henrik Raeder Clausen) writes: >>I'd like in 1.4 to have the System Requesters tell the user what file >>some program is looking for (like devs:disk-validator). This would be a > >This really doesn't make any sense. It's really the program's responsibility >to inform you what files it can't find. Some programs check for files in >several locations. But this shouldn't really matter; we're not talking about making *more* system requesters show up than already do, just about having them give more information once they do. Keep in mind, some programs try to find something somewhere, but do not consider it an error if they can't find it. Thus, you never know exactly what they're looking for. I recall when I first started using MicroEmacs, it would ask me to insert workbench every time I started it, but worked fine if I cancelled the requester. It took me several weeks before I got annoyed enough to systematically assign different things to RAM: until I found the one that MicroEmacs was using (probably s:). And sometimes, if a requester "mysteriously" comes up (I think disk-validator is a good example), I know *I* would like to know what is going on, to get an indication of whether I want to comply with the requester or save time by just cancelling it. Actually, what I would like to see is a *third* option in the system requester, between the other two, labeled "Why". That way, the regular system requester would have the same text (and not be cluttered), but if you wanted to find out exactly what was being looked for, "Why" would give you that extra information. -- Richard {tektronix,dual,sun,decvax,...}!ucbvax!ernie!carlson carlson@ernie.berkeley.edu
UH2@PSUVM.BITNET (Lee Sailer) (02/22/89)
In article <10204@pasteur.Berkeley.EDU>, carlson@betelgeuse (Richard L. Carlson) says: > > >Actually, what I would like to see is a *third* option in the system >requester, between the other two, labeled "Why". That way, the regular >system requester would have the same text (and not be cluttered), but >if you wanted to find out exactly what was being looked for, "Why" would >give you that extra information. > Something like this has been suggested before, and I like it. I think that choosing WHY could do more than just print an error message. Maybe volume XXX wasn't found because the user forgot to make an assign. The window that WHY pops up could be a file requestor type window with the capability of looking around through disks til the user finds the one he wants, and then saying "that's the one", making the assign, etc.
ba@m-net.UUCP (Bill Allen) (03/01/89)
Sender:
Reply-To: ba@m-net.UUCP (Bill Allen)
Followup-To:
Distribution:
Organization: M-NET, Ann Arbor, MI
Keywords:
>WB1.4+ wish list...
I'd be happy with simple CLI improvements like fixing
alias >file
You can't redirect the current alias list using >.
I guess because it's part of the shell window itself not an external
program.
--
---------------------------------------------------------
Reply-To: ba@m2-net.UUCP (Bill Allen Beogelein)
Organization: M-NET, Ann Arbor, MI
or call Sharewarer's BBS at 313-473-2020 24hrs, PCP thru MIDET, 100% Amiga