glmwc@marlin.jcu.edu.au (Matt Crowd) (01/27/91)
Ok, after using workbench 2.0 for a while, a friend and I came up with some ways to make it easier to use. Some would probably have to wait for 3.0, but others are pretty simple. BTW, Be warned, this is long, and mainly aimed at making the system more user friendly. 1) Leaving out icons is too longwinded. You should just be able to move the icon out and snapshot it. 2) Quiting workbench. Why should you be able to quit workbench without running any programs? You are left in a totally useless position! 3) It should be easier to stop the drives clicking. Maybe a preferences setting. Remember people should not have to use the CLI for ANYTHING! 4) Clock gripes : - Xoper says it uses 10% CPU time. Much higher than other clocks around - Two pixels too large, so it can't be hidden in the window title bar, which makes scrolling very slow (try running your stuff on a base 2000 with a 4 colour prod screen!) - Clock should be able to appear in the workbench screen title bar. If PD hacks and Macs can do it, there is a demand for it. 5) Backdrop feature. Press Amiga-B. Click the gadgets to move your icons off screen. Press Amiga-B. Hey man, where did all the icons go? How do I get them back? This will confuse novice users, even if most people can work out the obvious solution. 6) DisplayBeep() Totally gross. Change it fast. There is already a PD hack to do what it should do on a fish disk... 7) View by Size -> DOESN'T tell you the SIZE of a file. You can't find out a file size except using CLI. 8) No keyboard macro for delete. It is used more than some of the others yet there is no macro for it. 9) Ram Disk icon should always appear. IMHO. 10) Can't create icons from Workbench for files which don't have them. How many new computer users are going to realize they can load IconEdit and stuff around. If they are trying to get the system to automatically "more" a text file and it doesn't have an icon.... 11) Display a different Disk Icon for a Non-Dos Disk. Make it appear unuseable or something. 12) "The Icon(s) have no default tool" - change this message to english. 13) Detecting files It is simple to detect IFF sound/pic files. This should be done, and if the file doesn't have an icon/default tool, then Double clicking should display/play the file. There should be different default icons for different tools/IFF files. 14) CLI history gripe - personal gripe shared by some other people who use CLI i know. Under 2.0 con: selecting a command using the arrows puts the command into the history buffer again. This makes it more painful to re-execute a series of commands. An option maybe? or do we just download the replacement on fish? 15) CLI - info should display bytes not blocks. I don't know or care how large a block is! I try and use the % to work out how much is used. 16) Setting up IconX is too hard. There should be an easier way to do it. 17) No kill command for processes. A multitasking system without kill is incredible. We know this is tied into the incredible lack of resource tracking.... but..... 18) Lamer assign program. Nobody wants to know about assign. At least it should be easier to add an assign to the system. Nice requesters/help options etc. 19) Moving files should change tooltypes. The Mac can handle this. Otherwise a user can move a file, then wonder why it doesn't work when they click on it. I have seen people do this. They then proceed to click 10 times on it.... 20) DiskDoctor -> doesn't format for you 21) Format a disk from workbench - no options (FFS etc.) - bootable option. How are people supposed to know about install? Read the rather technical parts of the manual? 22) Can't empty trash unless trash can lid open! Stupid. BTW, a bug i found with it. Stick a file in it which has protection bits set so you cannot delete it. The file should have no icon. Open the trash window and show all files. Empty trash. The default icon disappears, there is no error message.... but the file stays there! 23) File Search. There is a very big need for a file search program. It should be useable from WB as well. 24) No mention of gurus in manual for Amiga 2000 25) No mention of color errors in bootup. 26) The most major gripe is how easy it is to crash the system. Other systems are getting memory protection. AmigaDOS needs it. At least provide a way for new programs written today to use memory protection and leave the old ones unprotected. Eventually, in about two years, most programs people run will be protected and the old system can be phased out. That's about all we could think of. Well, what do you think? Colin Adams/Matt Crowd
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/28/91)
In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > >8) No keyboard macro for delete. It is used more than some of the >others yet there is no macro for it. This is probably intentional. Deleting the wrong thing is extremely hazardous. I guess the user shall be protected from making errors by making this action a bit more complicated. >10) Can't create icons from Workbench for files which don't have >them. How many new computer users are going to realize they >can load IconEdit and stuff around. If they are trying to get the >system to automatically "more" a text file and it doesn't have an >icon.... Don't understand that. You CAN invoke IconEdit from the WB. Do you want it to become a menu item on the WB? If yes, then this is possible today with utilities like MyMenu (ok, not in normal shipment). >14) CLI history gripe - personal gripe shared by some other people >who use CLI i know. Under 2.0 con: selecting a command using >the arrows puts the command into the history buffer again. Not always! Only if you changed something in the line. And as the system can't simply detect whether your changes were only marginal or drastic, it can't treat them differently. >19) Moving files should change tooltypes. The Mac can handle this. >Otherwise a user can move a file, then wonder why it doesn't work >when they click on it. I have seen people do this. They then proceed >to click 10 times on it.... I think this (on the Mac) is due to the "Finder" concept. You can argue very much about it (good and bad). But I can imagine VERY difficult situations for the system to guess for new tooltypes paths. I fear this is impossible to solve in every situation. >20) DiskDoctor -> doesn't format for you Hmm, why should it??? >23) File Search. There is a very big need for a file search program. >It should be useable from WB as well. Huh? The CLI Search command does this! And you CAN invoke every CLI program from WB under 2.0. >25) No mention of color errors in bootup. Ok, would make some valid lines in the "Trouble shooting" part of the user manual. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
skank@iastate.edu (Skank George L) (01/30/91)
In article <1991Jan27.135843.2056@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >>6) DisplayBeep() Totally gross. Change it fast. There is already >>a PD hack to do what it should do on a fish disk... > > Personally, I like the flash better. I turn my sound down at night not to >wake others up, and the flash is nice. Also, sticking sound samples >in a DisplayBeep() routine slows the system down. If a BBS sends a bunch >of CTRL-Gs it takes up to 30 secs sometimes to play all the queued >sound requests. Additionally, I wouldn't want large sound samples hanging around in chip ram just so that the computer could beep (yawn, belch, fart, whatever). I also like the look of DisplayBeep(). If such a sound option were added, to DisplayBeep() then there should also be an option to turn the sound off and free up the resources. >>26) The most major gripe is how easy it is to crash the system. >>Other systems are getting memory protection. AmigaDOS needs it. >>At least provide a way for new programs written today to use >>memory protection and leave the old ones unprotected. Eventually, >>in about two years, most programs people run will be protected and >>the old system can be phased out. > > AmigaDOS as it is now will never have memory protection. AmigaDOS is >fast because it uses shared memory. There is lots of old GOOD software >that will not be updated, and thus unusable(maybe the company went under, or >the author isn't support it anymore). Its just as easy to crash the >Mac as it is with the Amiga if you have buggy software. What we need >is bug free software. Even with memory protection, a bad program will >crash, and you will lose your work. The rest of the system will >remain intact, but you still lost what you were working on. This is a pet peeve of mine. Memory protection is nice for developers but IT IS NOT AN EXCUSE FOR WRITING POOR SOFTWARE! A program that works, is fully debugged, tests for insufficient memory conditions, frees its resources, etc. does not need memory protection. --George -- George L. Skank | skank@iastate.edu |Fast cars, fast women, fast computers... Senior, Electrical Engineering |(not necessarily in that order)
glmwc@marlin.jcu.edu.au (Matt Crowd) (01/30/91)
In article <783@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >> >>8) No keyboard macro for delete. It is used more than some of the >>others yet there is no macro for it. > >This is probably intentional. Deleting the wrong thing is extremely >hazardous. I guess the user shall be protected from making errors by >making this action a bit more complicated. > There is a requester asking you if you really want to do it, it's good enough protection. >>10) Can't create icons from Workbench for files which don't have >>them. How many new computer users are going to realize they >>can load IconEdit and stuff around. If they are trying to get the >>system to automatically "more" a text file and it doesn't have an >>icon.... > >Don't understand that. You CAN invoke IconEdit from the WB. Do you >want it to become a menu item on the WB? If yes, then this is >possible today with utilities like MyMenu (ok, not in normal >shipment). What colin moent to say was that if workbench creates the icon for you it should create specialized ones for different files ie asm,iff, smus, etc. eg. tell workbench to create default icons for a group of text files and none of them will have `tool type' options ! >>19) Moving files should change tooltypes. The Mac can handle this. >>Otherwise a user can move a file, then wonder why it doesn't work >>when they click on it. I have seen people do this. They then proceed >>to click 10 times on it.... > >I think this (on the Mac) is due to the "Finder" concept. You can >argue very much about it (good and bad). But I can imagine VERY >difficult situations for the system to guess for new tooltypes >paths. I fear this is impossible to solve in every situation. > >>20) DiskDoctor -> doesn't format for you > >Hmm, why should it??? > Just the opther day i had a disk with a few corrupt sectors, i used diskdoctor on it and the disk sould have been restored to it's original state, not just locking out the sectors/files that were corrupt and telling me to copy the files to a new disk. >>23) File Search. There is a very big need for a file search program. >>It should be useable from WB as well. > >Huh? The CLI Search command does this! And you CAN invoke every CLI >program from WB under 2.0. > Are you referring to which?? This works from the directories with are in the current path and current dir. >>25) No mention of color errors in bootup. > >Ok, would make some valid lines in the "Trouble shooting" part of >the user manual. Include an explanation of the GURU numbers as well, thanks. > >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk Matt Crowd.
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > 2) Quiting workbench. Why should you be able to quit workbench > without running any programs? You are left in a totally useless > position! How does Workbench know if you have programs running or not? > 8) No keyboard macro for delete. It is used more than some of the > others yet there is no macro for it. And I'm glad there isn't! > 13) Detecting files > It is simple to detect IFF sound/pic files. This should be > done, and if the file doesn't have an icon/default tool, then > Double clicking should display/play the file. This is getting close to unwarranted chumminess with the applications. Besides, if the problem of not being able to create an icon from WB went away this would not be such a big deal. > 22) Can't empty trash unless trash can lid open! Stupid. You can have multiple trashcans, remember... one per volume. How is it to know which one you want to empty? It goes by the selected one. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan27.135843.2056@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > Nobody wants to know about assign?!?!? I SURE DO! it is easy to > add an assign to the system. "1> assign name: path/file" How much > easier can it get? A workbench assign tool would be nice. Sounds like a good PD program now there's a decent "system" interface. > AmigaDOS as it is now will never have memory protection. AmigaDOS is > fast because it uses shared memory. Shared memory and memory protection are not entirely opposed concepts. You could certainly get *more* protection than you have now. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <783@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > Don't understand that. You CAN invoke IconEdit from the WB. Do you > want it to become a menu item on the WB? No, what I (and I presume he) wants is the ability to set tool types and stuff on files that don't (initally) have an icon. When you do that it should create the .info file with all the default stuff (but maybe a slightly different icon) and put the tooltypes and other stuff into it. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/30/91)
In article <1991Jan30.073017.12620@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >In article <783@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > >>>23) File Search. There is a very big need for a file search program. >>>It should be useable from WB as well. >> >>Huh? The CLI Search command does this! And you CAN invoke every CLI >>program from WB under 2.0. >> >Are you referring to which?? This works from the directories with are in >the current path and current dir. No, I'm referring to the 2.0 version of the CLI program "Search", e.g. search sys: which file all ^^^^ -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/31/91)
In article <16165@sdcc6.ucsd.edu> cleland@sdbio2.ucsd.edu (Thomas Cleland) writes: >I do not personally own/use Workbench 2.0, but to the extent >that Colin and Matt's criticisms are still accurate I concur >on the majority of them. Amiga hackers need to learn that >most of the world doesn't enjoy seeking out replacement >console handlers from obscure academic network sites. I agree fully with you that it should not be needed for every user to get a replacement Shell or anything from outside to get to work with his machine. Commodore tries hard to provide all what is usefull already in the basic setup. > I noticed the first reply to Colin and >Matt's posting 'answered' most of their criticisms/suggestions >with hackers' answers. I hope you don't speak of my answer. Because I wanted to point out that at least the items mentioned by me are already "in there" or work only slightly different than asked for. I even hate the attitude of some "hackers" (as you call them) to not even consider what they have got with the machine because they have prejudices against original (Commodore) products and instantly grab for something that has a nice individual or else non-standard smell. Here at Commodore I mean that I should work with that equipment, also software-wise, which is basically provided. And I always found that this is not at all as limited as some of those hackers always state. Just by looking a little deeper into the provided manual I often found something new/creative what served me exceptionally well. So it is our problem to ask ourselves "Is it not intuitive enough how it is designed currently?" and "Did we explain that not well enough in the manuals? Did we explain it but hid it in a nice but never looked-at place in the manual?". So you can be sure that such wishes are at least considered in the latter aspect. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
skwood@acsu.buffalo.edu (Scott K Wood) (01/31/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >> 22) Can't empty trash unless trash can lid open! Stupid. >You can have multiple trashcans, remember... one per volume. How is it to >know which one you want to empty? It goes by the selected one. I always thought Commodore's implemantation of the Trashcan was off the wall. Why have Trashcan be a directory on EVERY disk? If ever the Mac did anything better than the Amiga, this is one case. There should be ONE trashcan that is in NO way related to a specific disk. One should be able to drag ANY files to this Trashcan and empty the trash. Multiple trashcans? What the point of that? The main concept behind the Trashcan is to delete files. Why do you need more than one? Scott >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>.
djohnson@beowulf.ucsd.edu (Darin Johnson) (01/31/91)
In article <7662@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >> 2) Quiting workbench. Why should you be able to quit workbench >> without running any programs? You are left in a totally useless >> position! > >How does Workbench know if you have programs running or not? Hmmm, how about having a double click in an empty workbench window raise a requester asking if Workbench or a CLI should be opened? Easy enough to do with a custom input handler, but then if you forget to run the handler... -- Darin Johnson djohnson@ucsd.edu - Political correctness is Turing undecidable.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/31/91)
In article <7666@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <783@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >> Don't understand that. You CAN invoke IconEdit from the WB. Do you >> want it to become a menu item on the WB? > >No, what I (and I presume he) wants is the ability to set tool types and >stuff on files that don't (initally) have an icon. When you do that it should >create the .info file with all the default stuff (but maybe a slightly >different icon) and put the tooltypes and other stuff into it. Ah, so this could be done by attaching an extra menu item like "Make permanent icon" to the "Icons" menu of the WB. You then would have to first invoke WB with "Window / Show / All Files", then click on the desired file (on its default icon), and call "Make permanent icon" from the menu. This would create a real .info file, initially looking like the default icon and carrying already the correct file type. You then would have to manually invoke "Information" from the menu to set the tool types (or calling this could be automatically included in the previous menu call). As last action you would have to invoke manually IconEdit to give the icon the shape you wish. Shouldn't be any difficult. Let's put this as an "enhancement request" into the West Chester database. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/31/91)
In article <7663@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan27.135843.2056@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >> Nobody wants to know about assign?!?!? I SURE DO! it is easy to >> add an assign to the system. "1> assign name: path/file" How much >> easier can it get? > >A workbench assign tool would be nice. Sounds like a good PD program now >there's a decent "system" interface. (It's obviously the day of BIG WB menus :-) So you want to click on a certain drawer (or file) and then invoke a menu item (in the "Icons" WB menu) named perhaps "Assign" and then a string requester opens where you can assign a name to this? Is this what you want? Like with that other posting I replied today already, this sounds not at all difficult. But is it really needed? >> AmigaDOS as it is now will never have memory protection. AmigaDOS is >> fast because it uses shared memory. > >Shared memory and memory protection are not entirely opposed concepts. You >could certainly get *more* protection than you have now. But one can argue whether "half" memory protection would be worth so much more than "no". -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/31/91)
In article <56933@eerie.acsu.Buffalo.EDU> skwood@acsu.buffalo.edu (Scott K Wood) writes: > Multiple trashcans? What the point of that? The main concept behind >the Trashcan is to delete files. Why do you need more than one? Because such "half-deleted" files thus remain on the volume they come from and perhaps will be needed again some day. Remember: The trashcan is not a full delete, you still have the possibility to recover files from there! Thus a data disk with many text files on it carries also the trashcan for letters, a spreadsheet data disk carries the trashcan for numeric data files. If you would want a single trashcan, you would have to *move* files from their home disk to the system disk to put it into the trashcan. And as you want to write to the system partition as rarely as possible, this would mean more risk for your system files. Also you would have to make your system partition bigger to hold all the trashcan files. This conflicts with the politics to make a small, closed partition for *only* system files. (Well, to avoid this, you could do an assign for a trashcan: drawer somewhere else, but I prefer the existing way.) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
glmwc@marlin.jcu.edu.au (Matt Crowd) (02/01/91)
In article <813@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <7663@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <1991Jan27.135843.2056@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >>> Nobody wants to know about assign?!?!? I SURE DO! it is easy to >>> add an assign to the system. "1> assign name: path/file" How much >>> easier can it get? >> >>A workbench assign tool would be nice. Sounds like a good PD program now >>there's a decent "system" interface. > >(It's obviously the day of BIG WB menus :-) >So you want to click on a certain drawer (or file) and then invoke >a menu item (in the "Icons" WB menu) named perhaps "Assign" and then >a string requester opens where you can assign a name to this? Is this >what you want? Like with that other posting I replied today already, >this sounds not at all difficult. But is it really needed? >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk It is partly the fault of software developers. After installing Ventura Publisher on an IBM, the installation software asks the user if he/she wants the autoexec.bat (startup-sequence) changed to include the path/ assignment for the installed program. If Amiga software did this, there wouldn't be so many problems with software installation for first time users. Matt.
robin@niksula.hut.fi (Jarto 'Robin' Tarpio) (02/01/91)
In article <56933@eerie.acsu.Buffalo.EDU> skwood@acsu.buffalo.edu (Scott K Wood) writes:
I always thought Commodore's implemantation of the Trashcan was off
the wall. Why have Trashcan be a directory on EVERY disk? If ever the Mac
did anything better than the Amiga, this is one case. There should be ONE
trashcan that is in NO way related to a specific disk. One should be able
to drag ANY files to this Trashcan and empty the trash.
Ok. Just wait a bit longer. I am about to finish my Trasher.
It is a nice AppWindow-trashcan where you can drag your icons
and it deletes them.
An other application could be to write a AppMore and AppView-
program that would show text, pics, play samples etc.
Scott
--
Jarto Tarpio StarSoft Ky
robin@niksula.hut.fi Helsinki University of Technologyhuebner@en.ecn.purdue.edu (Robert E. Huebner) (02/02/91)
In article <1991Feb1.010656.6638@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > >It is partly the fault of software developers. After installing Ventura >Publisher on an IBM, the installation software asks the user if he/she >wants the autoexec.bat (startup-sequence) changed to include the path/ >assignment for the installed program. If Amiga software did this, there >wouldn't be so many problems with software installation for first time >users. I'd like to see more of this too. I was pleasently suprised when installing Excellence 2.0. Not only did it alter the startup-sequence, but it seems to have actually looked for the spot where other assigns were made to insert the lines (I suppose this is in case you made ASSIGN resident for that portion of the process). However, I don't recall it actually asking my permission. It could be further improved by putting an IF EXISTS structure around it in case I choose to remove it from the HD. Overall I've noticed install procedures have been maturing rapidly in most software. Developers are catching on. -- | Robert E. Huebner | "Death is nature's way of telling | | huebner@en.ecn.purdue.edu | you to slow down" | | huebner@aerospace.aero.org | - Unknown Author |
cleland@sdbio2.ucsd.edu (Thomas Cleland) (02/02/91)
>>Multiple trashcans? What the point of that? The main concept behind >>the Trashcan is to delete files. Why do you need more than one? > [...] >The trashcan is a good organizer with a "throw-away" function built-in. >Normally if I am "backing up" copies of stuff that I will later throw away >I stuff them in the trashcan. I *always* want this data to remain associated >with the original data disk, but eventually I *will* delete it. If everything >went into the trashcan on my workbench disk it would quickly fill up (not to >mention that my workbench disks are all pretty much full - except for when I >boot my harddrive). > [...] >Actually I think that Commodore's trashcan makes a lot more sense than >Apple's, especially for those who do not yet have a harddrive (the majority >of Amiga owners). This is interesting. I'm not sure where the Apple trashcan actually stores its files--on the boot disk or in RAM. I have to assume the latter; although the Finder demands infinite disk swaps (floppy-only system) I don't recall dumping something in the Trashcan being one of those cases where it does. Actually, I take that back; I suspect that being put in the Apple trashcan simply sets some status bit on the file itself and puts some sort of pointer to that file in a "trashcan" directory in RAM. This is all a guess, but fits. Advantages and disadvantages. To best simulate Apple's trashcan for those who want it I suggest putting a Trashcan directory in the RAM disk and dragging it out onto the desktop (and using "Leave Out" under WB2.0). This will copy your files to RAM and take up space, though. The Amiga OS tends to do what it's told immediately, while the Mac often puts it off until later (which you can do if the OS controls disk removal exclusively). Thus, dragging something into a trashcan on a different volume would start a COPY command under AmigaDOS while the Mac OS can just shuffle pointers (if I'm correct) and wait to see if you delete the file or whatever before acting upon it in full. The Mac Trashcan is, to my tastes, superior on the surface, but imposes restrictions on the OS which aren't worth it (to me, based on my habits and preferences). So I prefer the Amiga package over the Mac package in this area (and most others). Of course, I could be completely wrong in my concept of the Mac trashcan structure. > _. >--Steve ._||__ DISCLAIMER: All opinions are my own. > Warren v\ *| ---------------------------------------------- > V {uunet,sun}!convex!swarren; swarren@convex.com -- // / Thom Cleland / It is easier / // / tcleland@ucsd.edu / to get forgiveness / \X/ / ASOCC * Amiga Users' Group at UCSD / than permission... / \____________________________________\____________________/
cleland@sdbio2.ucsd.edu (Thomas Cleland) (02/02/91)
>>> Nobody wants to know about assign?!?!? I SURE DO! it is easy to >>> add an assign to the system. "1> assign name: path/file" How much >>> easier can it get? >> >>A workbench assign tool would be nice. Sounds like a good PD program now >>there's a decent "system" interface. > >(It's obviously the day of BIG WB menus :-) >So you want to click on a certain drawer (or file) and then invoke >a menu item (in the "Icons" WB menu) named perhaps "Assign" and then >a string requester opens where you can assign a name to this? Is this >what you want? Like with that other posting I replied today already, >this sounds not at all difficult. But is it really needed? > I think it would be a good thing to make ASSIGNs pitifully easy. Lots of commercial software requires one to four ASSIGNs to be entered in the startup-sequence. Not difficult to us, but we're not selling to ourselves; we already have Amigas. I worked selling Amigas for some time and this has been my experience there as well as with computer-illiterate friends. The startup-sequence is a scary thing, particularly as it's split into startup-sequence and startupII. It's an invisible file (from a Workbench standpoint) in an invisible directory with a name that implies that you'll destroy your computer if you mess it up. You can put things in the wrong place, misspell words, and other errors that will prevent your machine from booting. Not a problem to us, but a serious one to the novice who wants to have a nice, menu-driven DTP package. Such people find their first interaction with the easy to use Amiga being working with "ED" typing cryptic words verbatim into a mystery file and courting serious disaster. Third party install scripts are notoriously poor. It was my hope that an icon-linked file of ASSIGN statements could be dragged into the WBStartup drawer under 2.0, thus enabling ASSIGNs to be made without getting into the threatening areas of the system. Is this true? I think that there should be some ridiculously easy way to add ASSIGNs permanently to the startup, through some self- explanatory requestor or phenomenally simple graphical mechanism like icon-dragging or menu-using. We must not forget how much of the market is somewhat scared of computers. -- // / Thom Cleland / It is easier / // / tcleland@ucsd.edu / to get forgiveness / \X/ / ASOCC * Amiga Users' Group at UCSD / than permission... / \____________________________________\____________________/
ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) (02/03/91)
A lot of people have debated the pros and cons of the Mac vs. Amiga trashcans. It's seems that is confusion about what does what. Here are a few of my observations, although I am certainly not a Mac expert. (1) Each Amiga disk can have a trashcan. Dragging something to the trashcan simply moves that file to the trashcan directory. There is sits until you click on the trash icon and choose "Empty Trash" from a workbench menu, at which point it is deleted from disk. Nice, clean, simple to understand. (2) The Mac trashcan sits on the desktop. From my observations, what must happen is something like this: When you drag a file to the Mac trashcan, the operating system somehow marks this file as having been put in the trash. It stays in that state until you chose "Empty Trash" from the desktop menu. But it's not quite that simple. Do you even notice how the trash gets emptied without your telling it to do so? Anytime there is disk activity on that disk, the trash gets emptied. Eject the disk. The trash is emptied. Write to the disk. The trash gets emptied. Bottom line: Put something in the Mac trashcan, you'll likely never get it back. Personally, I prefer the Amiga method. If I put it in the trashcan, I can get it out if I later change my mind. If I want to get rid of it for sure in the first place, I'll just choose discard from the workbench menu. Just my $.02 worth, Regard, Richard gerber@rigel.astro.uiuc.edu .
torrie@cs.stanford.edu (Evan J Torrie) (02/03/91)
ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes: >(2) The Mac trashcan sits on the desktop. From my observations, what >must happen is something like this: >When you drag a file to the Mac trashcan, the operating system somehow >marks this file as having been put in the trash. It stays in that state >until you chose "Empty Trash" from the desktop menu. But it's not quite >that simple. Do you even notice how the trash gets emptied without your >telling it to do so? Anytime there is disk activity on that disk, the >trash gets emptied. Eject the disk. The trash is emptied. Write to the >disk. The trash gets emptied. Bottom line: Put something in the Mac >trashcan, you'll likely never get it back. This is yet another one of those things that has been changed in System 7.0. In 7.0, the Mac trashcan is termed a container, just like any other disk. It keeps files until you explicitly empty it... I believe this works across reboots, although I have yet to work with System 7.0 - simply reading from pre-release information. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
david@kessner.denver.co.us (David Kessner) (02/03/91)
In article <1991Feb2.184118.3880@ux1.cso.uiuc.edu> ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes: >(1) Each Amiga disk can have a trashcan. Dragging something to the >trashcan simply moves that file to the trashcan directory. There is sits >until you click on the trash icon and choose "Empty Trash" >from a workbench menu, at which point >it is deleted from disk. Nice, clean, simple to understand. > >(2) The Mac trashcan sits on the desktop. From my observations, what >must happen is something like this: >When you drag a file to the Mac trashcan, the operating system somehow >marks this file as having been put in the trash. It stays in that state >until you chose "Empty Trash" from the desktop menu. But it's not quite >that simple. Do you even notice how the trash gets emptied without your >telling it to do so? Anytime there is disk activity on that disk, the >trash gets emptied. Eject the disk. The trash is emptied. Write to the >disk. The trash gets emptied. Bottom line: Put something in the Mac >trashcan, you'll likely never get it back. > >Personally, I prefer the Amiga method. If I put it in the trashcan, I can >get it out if I later change my mind. If I want to get rid of it for sure >in the first place, I'll just choose discard from the workbench menu. I like the NeXT's version of it. It isn't a trashcan at all-- it's a BLACK HOLE! This, of course, implies that you will never get anything out of it. While this may not be what you want, it sure is honest. - David -- David Kessner - david@kessner.denver.co.us | 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | This space for rent. This is my system so I can say any damn thing I want! |
peter@sugar.hackercorp.com (Peter da Silva) (02/03/91)
In article <813@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >A workbench assign tool would be nice. Sounds like a good PD program now > >there's a decent "system" interface. > (It's obviously the day of BIG WB menus :-) > So you want to click on a certain drawer (or file) and then invoke > a menu item (in the "Icons" WB menu) named perhaps "Assign" and then > a string requester opens where you can assign a name to this? No. Did I say "tool" and you read "menu"? No, I want a tool called "Assign" that I can open and get a list of assigns, or I drop a file into it and it asks pops up the string requestor you just described. It's not difficult. And it's really needed. > But one can argue whether "half" memory protection would be worth so > much more than "no". Yes, it would. Hell, even the 2 pennies worth you get from Enforcer is worth more than none. Really. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (02/03/91)
In article <1991Feb1.010656.6638@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > It is partly the fault of software developers. After installing Ventura > Publisher on an IBM, the installation software asks the user if he/she > wants the autoexec.bat (startup-sequence) changed to include the path/ > assignment for the installed program. The following setup would make this easier if standardised: 1> type s:user-startup .bra { .ket } echo "User configuration 1 Sep 90" list >ram:t/rc-temp s:rc/#?.rc nohead lformat="execute %s%s" execute ram:t/rc-temp echo "Completed user configuration" wait 5 1> .info amigavision.rc apps.rc aztec.rc beep.rc elvis.rc moon.rc noclick.rc terminals.rc tetrix.rc uucp.rc work.rc 1> [] -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (02/03/91)
In article <812@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > Ah, so this could be done by attaching an extra menu item like > "Make permanent icon" to the "Icons" menu of the WB. No, that's counterintuitive. Just leave all the gadgets on "information" active and create the icon on save, so icons act more consistent whether or not they're "real" or not. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
glmwc@marlin.jcu.edu.au (Matt Crowd) (02/04/91)
In article <7662@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan27.105252.7019@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >> 2) Quiting workbench. Why should you be able to quit workbench >> without running any programs? You are left in a totally useless >> position! > >How does Workbench know if you have programs running or not? You mean the Amiga resource tracking is this bad! I'm appalled. >> 8) No keyboard macro for delete. It is used more than some of the >> others yet there is no macro for it. > >And I'm glad there isn't! And I'm not. I mean there is a requester for it. >> 13) Detecting files > >> It is simple to detect IFF sound/pic files. This should be >> done, and if the file doesn't have an icon/default tool, then >> Double clicking should display/play the file. > >This is getting close to unwarranted chumminess with the applications. Besides, >if the problem of not being able to create an icon from WB went away this would >not be such a big deal. Agree about the ability to create a icon from WB. >> 22) Can't empty trash unless trash can lid open! Stupid. > >You can have multiple trashcans, remember... one per volume. How is it to >know which one you want to empty? It goes by the selected one. If the trashcan window is selected, it should know! It checks if the icon is selected, not if the trash window is open and selected. >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Colin.
tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) (02/04/91)
In article <1991Feb3.024311.23878@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >I like the NeXT's version of it. It isn't a trashcan at all-- it's a >BLACK HOLE! This, of course, implies that you will never get anything out >of it. While this may not be what you want, it sure is honest. > > - David It no loger exists... Black hole became a 'recycler bin'. It seems to do exactly what Amiga does, it also allows to recover any programs that are 're-cycled' as long as it's not emptied. +-----------------------------------------------------------+-------------+ | Yeo-Hoon Bae tinyguy@homer.cs.mcgill.ca | Amiga /// | | Dept. Computer Science, McGill University, Canada | 2000 /// | |-----------------------------------------------------------| \\\/// | | Amiga2000 + 5MB + 104MB HD + KX-P1124 + Mit. DiamondScan | \XX/ | +-----------------------------------------------------------+-------------+
dave@cs.arizona.edu (Dave P. Schaumann) (02/04/91)
It would be nice to have something like environment variables for icons with standard names, so that instead of having default tool be sys:utilities/more it could be $PAGER (or whatever syntax you like), and then if I *want* to use more to look at text files, I can have (in S:Startup-Sequence, most likely) something like "setenv PAGER=sys:utilities/more". Or (my personal preference) I could have "setenv PAGER=ram:MuchMore". That way, I wouldn't have to deal with eleventy-two different pagers, and their command structure. Surely this would be an easy thing to do. Dave Schaumann | And then -- what then? Then, future... dave@cs.arizona.edu | -Weather Report
sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) (02/04/91)
huebner@en.ecn.purdue.edu (Robert E. Huebner) writes: > I'd like to see more of this too. I was pleasently suprised when installing > Excellence 2.0. Not only did it alter the startup-sequence, but it seems > to have actually looked for the spot where other assigns were made to insert > the lines (I suppose this is in case you made ASSIGN resident for that > portion of the process). However, I don't recall it actually asking my > permission. It could be further improved by putting an IF EXISTS structure > around it in case I choose to remove it from the HD. > > Overall I've noticed install procedures have been maturing rapidly in most > software. Developers are catching on. You probably don't want to hear this but.... I just installed Windows 3.0 on a 386. The installation procedure was really very easy - not only would it ask you before it changed the autoexec/startup but it had the option of editing the changes before they happened, or saving the changed file with a different name so as to allow you to look at it and import only the changes you wanted. Now Windows 3.0's installation procedure probably had more work put into it than Workbench 2.0 or System 7's entire OS, but it was still something to aspire to. -- ** Official Signature for Sleeping Beagle (aka Thomas Farmer)! ** sbeagle@kennels.actrix.gen.nz || Disclaimers are for sick societies ** Thomas.Farmer@bbs.actrix.gen.nz || with too many lawyers.
ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) (02/04/91)
dave@cs.arizona.edu (Dave P. Schaumann) writes: >It would be nice to have something like environment variables for icons with >standard names, so that instead of having default tool be sys:utilities/more >it could be $PAGER (or whatever syntax you like), and then if I *want* to >use more to look at text files, I can have (in S:Startup-Sequence, most likely) >something like "setenv PAGER=sys:utilities/more". Or (my personal preference) >I could have "setenv PAGER=ram:MuchMore". That way, I wouldn't have to deal >with eleventy-two different pagers, and their command structure. >Surely this would be an easy thing to do. Absolutely great idea, Dave! And if the environmental variable wasn't set you could have the default be the default tool. Give this man a job, C=. Additionally, whenever the system can't find either the environmental variable or the default tool, have a requester inform the user of this fact and ask him if he would like to help find it. Then up pops a file requester a la AmigaVision, with which the user sets the path. (excuse me if this has been covered before, I've missed much of this thread). Regards, Richard gerber@rigel.astro.uiuc.edu
jeff@fang.clearpoint.com (Jeffrey J. Griglack) (02/04/91)
I think that the best way to improve WB 2.0 would be to release it for the 500, 2000 and 3000. What's the holdup guys? Jeff Griglack -- Jeff Griglack | Yea, I feel terrible. I should be forced to jeff@fang.clearpoint.com | see "Cats" again. --From "30 Something"
rjc@geech.ai.mit.edu (Ray Cromwell) (02/04/91)
In article <1991Feb4.134336.23501@ux1.cso.uiuc.edu> ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes: >dave@cs.arizona.edu (Dave P. Schaumann) writes: > > >>It would be nice to have something like environment variables for icons with >>standard names, so that instead of having default tool be sys:utilities/more >>it could be $PAGER (or whatever syntax you like), and then if I *want* to >>use more to look at text files, I can have (in S:Startup-Sequence, most likely) >>something like "setenv PAGER=sys:utilities/more". Or (my personal preference) >>I could have "setenv PAGER=ram:MuchMore". That way, I wouldn't have to deal >>with eleventy-two different pagers, and their command structure. > >>Surely this would be an easy thing to do. > >Absolutely great idea, Dave! And if the environmental variable wasn't set >you could have the default be the default tool. Give this man a job, C=. > >Additionally, whenever the system can't find either the environmental >variable or the default tool, have a requester inform the user of this >fact and ask him if he would like to help find it. Then up pops a file >requester a la AmigaVision, with which the user sets the path. (excuse >me if this has been covered before, I've missed much of this thread). > >Regards, >Richard >gerber@rigel.astro.uiuc.edu PROPOSAL: Why don't we all particpate in developing some standard Environment variables for applications to use. Then future updates and new programs could support them. Since env vars are on the 'user' side of things, and since users are the ones who are going to be using them, it should be only fitting that we develop their meanings. So follow-up on this post and attach your favorite env-var name and what it does. I'll start it off.. $EDITOR=path/name of default editor to use $PAGER=path/name of pager (less,more,leggi, ppmore, etc) $PAINT=paint program $VIEW=iff picture viewer $PLAY=smus/med player $MOVIE=anim player $TERM=term What are the benifits of env vars? How many times has a program assumed the path of a program. Like a picture file looking for 'myhd:picviewer' ? Of course you have to edit it with the info command. With env vars, the Icon can just execute '$VIEW'. Optionally you could even specify your favorite command line options. One problem with this is, neither WB nor AmigaShell support wildcard expansion. Until Commodore adds env var support in icons, it will have to be hacked with an iconx script. The tooltype of pictures/music/textfiles, etc would have to execute s:envexpand which would GetEnv the var and execute it. Any ideas?
peter@sugar.hackercorp.com (Peter da Silva) (02/05/91)
In article <1991Feb3.101342.8383@news.iastate.edu> skank@iastate.edu (Skank George L) writes: > I'm not sure if this is needed, but how 'bout a REXX bit in the file > system, like the pure bit except for REXX programs... Better would be a method of including a comment with the file to describe what interpreter to use. It can't be in the file itself because, unlike UNIX, it's too late to standardize comment conventions. How about putting it in the filenote? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (02/05/91)
In article <1991Feb4.012848.13868@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > In article <7662@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >How does Workbench know if you have programs running or not? > You mean the Amiga resource tracking is this bad! I'm appalled. This has nothing to do with resource tracking. The Workbench is *not* the only way programs can come into existence. I have a pretty minimum set of programs running, but there are still lots of tasks out there. Now, quick, is it OK for Workbench to close or not? ADDRESS Q PRI WAITSIG TYPE NAME 7f0e342 W 0 f0000000 TASK console.device 7f319a0 W 0 80001000 CLI 2 Background Process 7f42fc8 W 4 c0000000 PROCESS RexxMaster 7f2b468 W 0 10 PROCESS ramlib 7f46670 W 1 c0000000 TASK 3bc10 W 0 100 PROCESS SYS:System/CLI 7f17388 W 10 40000100 PROCESS DF0 7f1fb10 W 10 40000100 PROCESS Peter 7f25948 W 10 40000100 PROCESS Stephanie 7f5ae58 W 1 c0000000 CLI 3 Workbench 7f547d8 W 0 e2000000 PROCESS JR-Comm 7f0fb08 W 5 300 TASK trackdisk.device 7f08af2 W 20 c0000000 TASK input.device 7f41d68 W 0 f8000000 TASK jrcomm-clock 7f115f0 W 10 40000100 PROCESS WB_2.x 7f0afd0 W 12 c0000000 TASK SCSI bus handler 7f0a3f8 W 11 e0000000 TASK scsi.device 7f19ac0 W 10 40000100 PROCESS Work 7f31060 W 0 c0000100 PROCESS RAM 3d950 W 5 100 PROCESS CON (20 jobs 0 ready) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
andy@cbmvax.commodore.com (Andy Finkel) (02/05/91)
In article <1991Feb3.101342.8383@news.iastate.edu> skank@iastate.edu (Skank George L) writes: > > I'm not sure if this is needed, but how 'bout a REXX bit in the file >system, like the pure bit except for REXX programs, then when you type a >filename with the REXX bit set it sends the input to the REXX interpreter >and you don't have to keep typing 'rx filename' (maybe this isn't needed, >it's been a month or two since I last read my AREXX docs). We have one of those; we use the script bit. If the script bit is set, the shell knows its a script, and looks at the file to determine what interpreter wants to handle it. It's kind of extensible, by letting the execute command make the decision as to what interpreter gets to run the script. andy > --George -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
skwood@acsu.buffalo.edu (Scott K Wood) (02/05/91)
ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes: >A lot of people have debated the pros and cons of the Mac vs. Amiga >trashcans. It's seems that is confusion about what does what. Here are >a few of my observations, although I am certainly not a Mac expert. >(2) The Mac trashcan sits on the desktop. From my observations, what >must happen is something like this: >When you drag a file to the Mac trashcan, the operating system somehow >marks this file as having been put in the trash. It stays in that state >until you chose "Empty Trash" from the desktop menu. But it's not quite >that simple. Do you even notice how the trash gets emptied without your >telling it to do so? Anytime there is disk activity on that disk, the >trash gets emptied. Eject the disk. The trash is emptied. Write to the >disk. The trash gets emptied. Bottom line: Put something in the Mac >trashcan, you'll likely never get it back. Obviously DELETEING a file is the WHOLE purpose of putting something in the Trashcan. Many people before you have also said that with the Amiga Trashcan, you have the option of taking something out if you decide that you want it again. Perhaps the real solution to that problem is to never put it in the Trashcan in the FIRST place. If you aren't sure about deleting something, leave it in it's original directory. Second comment: Since each Amiga disk can have a Trashcan there is an Empty Trash menu item, why in 1.0 - 1.3 (I don't know if 2.0 has this) versions of Workbench was there ALSO a DISCARD menu item? As far as I could tell, it perfoormed the exact same function MUCH faster than the Trashcan. Was there something special about the DISCARD command that made it different than putting something in the Trashcan and then Emptying the Trash. It was because of this command that I never had a Trashcan on my disks. If I was using CLI, I would use the delete command. If I was using WB, just select the items that DISCARD them. Scott
swarren@convex.com (Steve Warren) (02/05/91)
In article <57742@eerie.acsu.Buffalo.EDU> skwood@acsu.buffalo.edu (Scott K Wood) writes: [...] > Obviously DELETEING a file is the WHOLE purpose of putting something >in the Trashcan. Obviously you don't know what you are talking about. You present your opinion as an axiom, then you complain about the features which prove that your opinion is unfounded. > ... Many people before you have also said that with the Amiga >Trashcan, you have the option of taking something out if you decide that >you want it again. Perhaps the real solution to that problem is to never >put it in the Trashcan in the FIRST place. If you aren't sure about >deleting something, leave it in it's original directory. Yes sir, I'll do whatever you say, sir. ;^) Look, if you can't comprehend why people would want organize stuff that they may want to delete into one directory, then don't worry about it. Believe me when I tell you it's a feature. > Second comment: Since each Amiga disk can have a Trashcan there is >an Empty Trash menu item, why in 1.0 - 1.3 (I don't know if 2.0 has this) >versions of Workbench was there ALSO a DISCARD menu item? As far as I could >tell, it perfoormed the exact same function MUCH faster than the Trashcan. Because you are mistaken about the trashcan. Obviously DELETING a file is the WHOLE purpose of the DISCARD menu item. Therefore, obviously there is more purpose to the trashcan than just deleting files. >Was there something special about the DISCARD command that made it different >than putting something in the Trashcan and then Emptying the Trash. It was >because of this command that I never had a Trashcan on my disks. If I was >using CLI, I would use the delete command. If I was using WB, just select >the items that DISCARD them. Why are you bitching about features you never use? If you are happy with the delete function then have fun with it! Sheesh! OK, I'll tell you why it's a feature. Until I run out of space on a floppy I see no reason to delete files on it. So I can usually recover stuff if I make a mistake. This is a good feature for me. If you can't benefit from it then fine. But get out of my face, Ace. -- _. --Steve ._||__ DISCLAIMER: All opinions are my own. Warren v\ *| ---------------------------------------------- V {uunet,sun}!convex!swarren; swarren@convex.com
dac@prolix.ccadfa.oz.au (Andrew Clayton) (02/05/91)
In article <1991Feb3.101342.8383@news.iastate.edu>, Skank George L writes: > > I'm not sure if this is needed, but how 'bout a REXX bit in the file > system, like the pure bit except for REXX programs, then when you type a > filename with the REXX bit set it sends the input to the REXX interpreter > and you don't have to keep typing 'rx filename' (maybe this isn't needed, > it's been a month or two since I last read my AREXX docs). > --George Try aliasing the name - Alias my.rexx.script rx my.rexx.script, in your s:Shell-Startup file. > George L. Skank | Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac@munnari.OZ.AU . . I am. --------------Phone +61 6 285 2537 (+10GMT) // I cannot currently send email.
dtiberio@csserv1.ic.sunysb.edu (David Tiberio) (02/05/91)
In article <1659@crackers.clearpoint.com> jeff@fang.clearpoint.com (Jeffrey J. Griglack) writes: > >I think that the best way to improve WB 2.0 would be to release it for the >500, 2000 and 3000. What's the holdup guys? > >Jeff Griglack > >-- > >Jeff Griglack | Yea, I feel terrible. I should be forced to >jeff@fang.clearpoint.com | see "Cats" again. --From "30 Something" WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. DavidTiberio SUNYStonyBrook2-3605 AMIGA TotoProductions DDDMEN
d87-khd@sm.luth.se (Karl-Gunnar Hultland) (02/05/91)
dtiberio@csserv1.ic.sunysb.edu (David Tiberio) writes: >In article <1659@crackers.clearpoint.com> jeff@fang.clearpoint.com (Jeffrey J. Griglack) writes: >> >>I think that the best way to improve WB 2.0 would be to release it for the >>500, 2000 and 3000. What's the holdup guys?{ > WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. Wrong I've tried the rom pre-release on a A2000A(the German model) with 512 kB Chip and Agnus and it works like a dream. Karl -- // // // \\ // // \\ // \\ // Karl Hultland,(d87-khd@sm.luth.se) \X/ \X/ \X/ University of Lulea,Sweden 500 2000 3000 I have called this principle, by which each slight variation, if useful, is preserved, by the term of Natural Selection. /C. Darwin
peterk@cbmger.UUCP (Peter Kittel GERMANY) (02/05/91)
In article <57742@eerie.acsu.Buffalo.EDU> skwood@acsu.buffalo.edu (Scott K Wood) writes: > > Obviously DELETEING a file is the WHOLE purpose of putting something >in the Trashcan. Many people before you have also said that with the Amiga >Trashcan, you have the option of taking something out if you decide that >you want it again. That's the difference: From the trashcan, you can recover a file, but... > Second comment: Since each Amiga disk can have a Trashcan there is >an Empty Trash menu item, why in 1.0 - 1.3 (I don't know if 2.0 has this) >versions of Workbench was there ALSO a DISCARD menu item? Discard really and instantly deletes it. In 2.0 this function is renamed to Delete. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peterk@cbmger.UUCP (Peter Kittel GERMANY) (02/05/91)
In article <1991Feb4.213757.27047@sbcs.sunysb.edu> dtiberio@csserv1.ic.sunysb.edu (David Tiberio) writes: >In article <1659@crackers.clearpoint.com> jeff@fang.clearpoint.com (Jeffrey J. Griglack) writes: >> >>I think that the best way to improve WB 2.0 would be to release it for the >>500, 2000 and 3000. What's the holdup guys? > > WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. PLEASE, ALL here! STOP telling lies! When we talk about 2.0 going sometime to the smaller models, we definitely speak about 2.0 *in ROM*. NOWHERE in 2.0 is a need for 1 MB Chip RAM! And as the OS sits in ROM, it also won't take 540 KB of the RAM. But the OS is still not ready for ROM, so PLEASE be a little patient, ok? -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jbickers@templar.actrix.gen.nz (John Bickers) (02/05/91)
Quoted from <779@caslon.cs.arizona.edu> by dave@cs.arizona.edu (Dave P. Schaumann): > It would be nice to have something like environment variables for icons with > standard names, so that instead of having default tool be sys:utilities/more > it could be $PAGER (or whatever syntax you like), and then if I *want* to Like aliases for Workbench? This has been done (for example, I alias More, MuchMore, Less, etc to a single text display program). > Dave Schaumann | And then -- what then? Then, future... -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
dac@prolix.ccadfa.oz.au (Andrew Clayton) (02/05/91)
In article <5Juuw4w163w@kennels.actrix.gen.nz>, Sleeping Beagle writes: > huebner@en.ecn.purdue.edu (Robert E. Huebner) writes: > > > Overall I've noticed install procedures have been maturing rapidly in most > > software. Developers are catching on. > > You probably don't want to hear this but.... Correct. But you went on and posted it, so now you'll suffer the consequences of your actions: > I just installed Windows 3.0 on a 386. Yeah. 11.9Mb of stuff, just to implement an environment that is kludgy, awkward, memory hungry, and resource voracious! Dead brilliant. AmigaDos 1.3 is, by comparison, a 256K rom image, and a few programs, and provides ALL of what Windows 3 does, and more, in a better, cleaner, faster, and overall, a far more hoopy fashion, than old Mickeysoft did with their Windows guff. However, since Windows 3 is not the gist of your message, just take my flame text as an indication of my level of dissatisfaction with your arrogant smugness regarding: > The installation procedure was really very easy As long as you have a spare 11.9Mb of disk space lying around ... > - not only would it ask you before it changed > the autoexec/startup but it had the option of editing the changes > before they happened, or saving the changed file with a different > name so as to allow you to look at it and import only the changes > you wanted. Golly. So Mickeysoft have learnt the art of COPYING text files now, and SAVING backups of them, that you can revert to in case their (usually hopeless) abortive INSTALL procedures happen to make a complete pigs breakfast of the entire operation. Chalk one up to Microsoft's technical wizards for that, eh. How difficult is it to ASK for information from a user, and act upon the response? When I purchased M2Sprint Modula 2 (by Martin Taillefer), it came with an install program that modified one's startup-sequence, gave you full control over which drive, partition, and directory you wanted to place the environment on, had large, medium and small memory models catered for (deciding whether to configure the environment to load all the include, link and symbol files into a RAD: disk, or merely the compiler and editor, or nothing at all), and did it all neatly and effectively, with a fully intuitionized interface, in a mere 19K file. How humungously oversized was this Windows 3 install program? How many overlays were needed to get it running? How long did it take to achieve it's 'magic'. How much money, indeed, time, did this miracle of modern software engineering set you back? All for a suite of programs that, (and I quote a rabid IBM lover here) "Is really only good for playing a neat game of solitaire". > Now Windows 3.0's installation procedure probably had more work > put into it than Workbench 2.0 or System 7's entire OS, Wotawanka! > but it was still something to aspire to. ... if you were used to installation procedures for more archaic machines, such as TRS-80's, IBM MVS machines, or perhaps a HP 41C calculator. Afraid that your 'yew bewt' example, was nothing more than a disguised IBM Vs Amiga flame. > ** Official Signature for Sleeping Beagle (aka Thomas Farmer)! Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac@munnari.OZ.AU . . I am. --------------Phone +61 6 285 2537 (+10GMT) // I cannot currently send email.
peter@sugar.hackercorp.com (Peter da Silva) (02/06/91)
In article <1991Feb4.151637.5868@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > $EDITOR=path/name of default editor to use > $PAGER=path/name of pager (less,more,leggi, ppmore, etc) > $PAINT=paint program > $VIEW=iff picture viewer > $PLAY=smus/med player > $MOVIE=anim player > $TERM=term By this do you mean "term = terminal program", "term = what that program is emulating", or "term = what I have plugged into my serial port"? Suggestions: $SHELL=preferred shell $NAME=your full name (why not?) $USAGE=level of help messages desired from CLI commands -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
rjc@geech.ai.mit.edu (Ray Cromwell) (02/06/91)
In article <10961.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991Feb4.151637.5868@mintaka.lcs.mit.edu> by rjc@geech.ai.mit.edu (Ray Cromwell): >> Any ideas? > > I do the following to set up a path, a resident list, and an alias > list when I start Workbench: > > 'wb-back' > 'wb-resi dh0:utils/ty dh0:utils/mostra' > 'wb-alias more ty less ty muchmore ty most ty' > 'wb-alias viewilbm mostra seeall mostra show mostra display mostra\ > superview mostra showpics mostra' > 'wb-path dh0:utils' > > I'd prefer a built-in alias/path system like the CLI uses, that could > access the same lists. Great! I sure wish I had WB2.0. If I did, I may actually put LoadWB back on my boot disk. ENV vars are still useful, especially for programming rexx/s-s's. >-- >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** >*** "Patterns multiplying, re-direct our view" - Devo. ***
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) (02/06/91)
rjc@geech.ai.mit.edu (Ray Cromwell) writes:
< PROPOSAL:
<
< Why don't we all particpate in developing some standard Environment
< variables for applications to use. Then future updates and new programs
< could support them. Since env vars are on the 'user' side of things,
< and since users are the ones who are going to be using them, it should be
< only fitting that we develop their meanings. So follow-up on this post
< and attach your favorite env-var name and what it does.
<
< I'll start it off..
<
<
< $EDITOR=path/name of default editor to use
< $PAGER=path/name of pager (less,more,leggi, ppmore, etc)
< $PAINT=paint program
< $VIEW=iff picture viewer
< $PLAY=smus/med player
< $MOVIE=anim player
< $TERM=term
<
< What are the benifits of env vars? How many times has a program
< assumed the path of a program. Like a picture file looking for 'myhd:picviewer'
< ? Of course you have to edit it with the info command.
<
< With env vars, the Icon can just execute '$VIEW'. Optionally you could even
< specify your favorite command line options. One problem with this is,
< neither WB nor AmigaShell support wildcard expansion. Until Commodore adds
< env var support in icons, it will have to be hacked with an iconx script.
< The tooltype of pictures/music/textfiles, etc would have to execute
< s:envexpand which would GetEnv the var and execute it.
<
< Any ideas?
This is similar to the notion adopted by SKsh. You can create a file
(only needs to happen once) containing information about given TYPES
of files (ILBM, 8SVX, SMUS, text, binary, etc.), and provide the name of
the program you want to run when each type of file is encountered.
SKsh has a program called 'view', which takes one or more files as
arguments, and then makes a best guess from your parameter file as to
which program suits each file. It would seem possible to modify such a
program to use WB arguments, and possibly simplify the maintenance of
the parameter file. Then, for a given file, you would simply make its
default tool 'view', and let IT figure out which program to run, where
to find it, what arguments it needs, whether it requires a console
window, etc.
How does this sound?
--
Chris (Insert phrase here) Seaman | ___-/^\-___
cseaman@gateway.sequent.com <or> | //__--\O/--__\\ nI' yIyIn 'ej yIchep.
...!uunet!sequent!cseaman | // \\
The Home of the Killer Smiley | `\ /'skank@iastate.edu (Skank George L) (02/06/91)
In article <18543@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >In article <1991Feb3.101342.8383@news.iastate.edu> skank@iastate.edu (Skank George L) writes: >> >> I'm not sure if this is needed, but how 'bout a REXX bit in the file >>system, like the pure bit except for REXX programs, then when you type a >>filename with the REXX bit set it sends the input to the REXX interpreter >>and you don't have to keep typing 'rx filename' (maybe this isn't needed, >>it's been a month or two since I last read my AREXX docs). > >We have one of those; we use the script bit. If the script >bit is set, the shell knows its a script, and looks at >the file to determine what interpreter wants to handle it. > >It's kind of extensible, by letting the execute command >make the decision as to what interpreter gets to run >the script. > > andy > >> --George > >-- >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. Wow, I didn't realize the 's' bit applied to ARexx scripts too. I'll have to go home and try that... :-) --George -- George L. Skank | skank@iastate.edu |Fast cars, fast women, fast computers... Senior, Electrical Engineering |Not necessarily in that order
skank@iastate.edu (Skank George L) (02/06/91)
In article <18a2e75c.ARN2927@prolix.ccadfa.oz.au> ccadfa.cc.adfa.oz.au!prolix!dac@munnari.OZ.AU writes: >In article <5Juuw4w163w@kennels.actrix.gen.nz>, Sleeping Beagle writes: > >> huebner@en.ecn.purdue.edu (Robert E. Huebner) writes: >> >>> Overall I've noticed install procedures have been maturing rapidly in most >>> software. Developers are catching on. > >How difficult is it to ASK for information from a user, and act upon the >response? > >When I purchased M2Sprint Modula 2 (by Martin Taillefer), it came with an >install program that modified one's startup-sequence, gave you full control >over which drive, partition, and directory you wanted to place the environment >on, had large, medium and small memory models catered for (deciding whether to >configure the environment to load all the include, link and symbol files into >a RAD: disk, or merely the compiler and editor, or nothing at all), and did >it all neatly and effectively, with a fully intuitionized interface, in a mere >19K file. [verbose Windows 3.0 installation (and appropriate flames deleted)] Since Excellence 2.0 was what sparked this thread I have to jump in and say that Excellence's installation procedure is (as was previously stated) *very* user friendly and allows the user complete control over all paths. I also have Lattice C version 5.10(?) and must say that it also installed itself (all 6 disks) very nicely on my A3000. I did have to create an alias for dh0: (granted not so user friendly), but the installation procedure went smoothly afterward. For those of you who would argue that that is not something that a new user would think to do, well, I was a new user when I did it, having only received my A3000 the week before. --George -- George L. Skank | skank@iastate.edu |Fast cars, fast women, fast computers... Senior, Electrical Engineering |Not necessarily in that order
jbickers@templar.actrix.gen.nz (John Bickers) (02/06/91)
Quoted from <1991Feb4.151637.5868@mintaka.lcs.mit.edu> by rjc@geech.ai.mit.edu (Ray Cromwell): > What are the benifits of env vars? How many times has a program > assumed the path of a program. Like a picture file looking for 'myhd:picviewer' One problem is that programs often assume the arguments a sub-program will take, as well as it's name. > The tooltype of pictures/music/textfiles, etc would have to execute > s:envexpand which would GetEnv the var and execute it. > > Any ideas? I do the following to set up a path, a resident list, and an alias list when I start Workbench: 'wb-back' 'wb-resi dh0:utils/ty dh0:utils/mostra' 'wb-alias more ty less ty muchmore ty most ty' 'wb-alias viewilbm mostra seeall mostra show mostra display mostra\ superview mostra showpics mostra' 'wb-path dh0:utils' I'd prefer a built-in alias/path system like the CLI uses, that could access the same lists. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (02/06/91)
glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > It is partly the fault of software developers. After installing Ventura > Publisher on an IBM, the installation software asks the user if he/she > wants the autoexec.bat (startup-sequence) changed to include the path/ > assignment for the installed program. peter@sugar.hackercorp.com (Peter da Silva) writes: =| The following setup would make this easier if standardised: =| =| 1> type s:user-startup =| .bra { =| .ket } =| =| echo "User configuration 1 Sep 90" =| list >ram:t/rc-temp s:rc/#?.rc nohead lformat="execute %s%s" =| execute ram:t/rc-temp =| echo "Completed user configuration" =| wait 5 I suppose this is a dir output: =| 1> =| .info amigavision.rc =| apps.rc aztec.rc =| beep.rc elvis.rc =| moon.rc noclick.rc =| terminals.rc tetrix.rc =| uucp.rc work.rc Does this signify anything? =| 1> [] This is a good idea to become a Commodore standard. Questions: Would you need to segregate stuff into once per boot stuff and once per shell stuff, or can you really do it once and for all at the start? I do agree that this make things considerably more straightforward, though the eventual name space or "assign" collision is bound to occur. At least this way things are in small, easy to repair, well labeled pieces, and the install script for any one product can be fairly simple minded. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (02/06/91)
skank@iastate.edu (Skank George L) writes: > I'm not sure if this is needed, but how 'bout a REXX bit in the file > system, like the pure bit except for REXX programs... peter@sugar.hackercorp.com (Peter da Silva) writes: > Better would be a method of including a comment with the file to > describe what interpreter to use. It can't be in the file itself > because, unlike UNIX, it's too late to standardize comment > conventions. How about putting it in the filenote? Probably not. The Amiga community (at least the part we see here, and who else gets a vote? ;-) tends to ship a lot of software from system to system, including unpacking and repacking it on various hosts. I think a filenote would not survive this process, right? Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
davewt@NCoast.ORG (David Wright) (02/06/91)
In article <1991Feb4.213757.27047@sbcs.sunysb.edu> dtiberio@csserv1.ic.sunysb.edu (David Tiberio) writes: > WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. WorkBench 2.0 (really AmigaDOS 2.0) does NOT require 1mb of chip RAM. This has been said over and over again, even in the old Amiga World article which showed a very early version of it. It will USE the 1mb of chip RAM for extended graphics modes (if you have the newer graphics chips), but it is NOT required to use AmigaDOS 2.0. And probobly the only reason that KickStart is over 512k is the overhead for the filing system, or the format they chose to store it on disk. After all, it has to fit onto 512k of ROM when it is done, which means there is no technical reason it could not be produced for any machine but the 1000 in ROM form. Dave
forgeas@swinjm.UUCP (Jean-Michel Forgeas) (02/06/91)
In article <1991Feb4.213757.27047@sbcs.sunysb.edu>, David Tiberio writes: > WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. Wrong! I work under 2.0 and my A2000A have only 512K of chip ram. the kickfile is exactly 512K and is loaded in fast ram. -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?
kent@swrinde.nde.swri.edu (Kent D. Polk) (02/06/91)
In article <1991Feb5.224541.22550@news.iastate.edu> skank@iastate.edu (Skank George L) writes: > > Since Excellence 2.0 was what sparked this thread I have to jump in and >say that Excellence's installation procedure is (as was previously stated) >*very* user friendly and allows the user complete control over all paths. However, I would vote for GfxBase's X11 installation software as the MOST ORIGINAL software installation technique. It installs 8 (I think) disks of lharc'ed software without a glitch. It can be a bit mind-bending the first time you see it take off though. Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) (02/07/91)
dtiberio@csserv1.ic.sunysb.edu (David Tiberio) writes: > WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. No it doesn't. It seems to require about 100k actually... (Although you won't have any left if that's all you have!) What it deos require is enough RAM to load the ROMS into... -- ** Official Signature for Sleeping Beagle (aka Thomas Farmer)! ** sbeagle@kennels.actrix.gen.nz || Disclaimers are for sick societies ** Thomas.Farmer@bbs.actrix.gen.nz || with too many lawyers.
davewt@NCoast.ORG (David Wright) (02/08/91)
In article <1991Feb2.230104.27338@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > This is yet another one of those things that has been changed in >System 7.0. In 7.0, the Mac trashcan is termed a container, just like >any other disk. It keeps files until you explicitly empty it... I >believe this works across reboots, although I have yet to work with >System 7.0 - simply reading from pre-release information. Ahh. Yet another thing that the Mac is just now getting that the Amiga has had all along, and even now does better. Dave
davewt@NCoast.ORG (David Wright) (02/08/91)
In article <57742@eerie.acsu.Buffalo.EDU> skwood@acsu.buffalo.edu (Scott K Wood) writes: > Second comment: Since each Amiga disk can have a Trashcan there is >an Empty Trash menu item, why in 1.0 - 1.3 (I don't know if 2.0 has this) >versions of Workbench was there ALSO a DISCARD menu item? As far as I could >tell, it perfoormed the exact same function MUCH faster than the Trashcan. >Was there something special about the DISCARD command that made it different >than putting something in the Trashcan and then Emptying the Trash. It was >because of this command that I never had a Trashcan on my disks. If I was >using CLI, I would use the delete command. If I was using WB, just select >the items that DISCARD them. Which is probobly what most people do. The purpose of the trashcan is to provide a special directory on each disk where you can put files that you think you MIGHT want to delete, or that you no longer need. If you are SURE you don't need a file, you can just use the discard (or "delete" as it is called under 2.0) menu item, and save yourself the extra step of selecting and emptying the trash. But if you just want to get rid of a file, or get rid of a bunch at once, in a safe way (how many times have you used a wildcard to delete a group of files under AmigaDOS or Unix and relized too late that you removed a couple other files as well?), the trashcan works nicely. You can just leave it alone and empty the trash when the disk starts to fill up or you have verified you don't want any of the files. Dave
davewt@NCoast.ORG (David Wright) (02/08/91)
In article <1991Feb4.012848.13868@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >>How does Workbench know if you have programs running or not? > >You mean the Amiga resource tracking is this bad! I'm appalled. And just what does resource tracking have to do with it? You don't need WorkBench to run software, and in fact, any program can use the CloseWorkBench function to *try* and close WorkBench if there are no more active WORKBENCH LAUNCHED programs. This is what he really should have said. If you run a program from the CLI, you may WANT WorkBench to close. And it is trivial to have a program running that can look at the keyboard and reopen WorkBench if a certain key is pressed. Do you complain that your car's transmission lets you shift into reverse while you are doing 55? Or shift from 5th to 1st at 85? Why should the machine pretend to assume it knows best? >>> 22) Can't empty trash unless trash can lid open! Stupid. ... >If the trashcan window is selected, it should know! It checks if >the icon is selected, not if the trash window is open and selected. A window has nothing to do with an icon, and vice-versa. Why should an Intuition object (the window) know anything about a WorkBench-specific object (the icon)? That would defeat the whole point of an object-oriented programming environment. This isn't a Mac, where selecting a window pops it to the front. Whether the window is open or not, or selected or not is irrelevant to whether the trashcan ICON is selected. When you have the trashcan WINDOW selected, you are working INSIDE the trashcan. This would be like holding your hand inside the trashcan while you are trying to empty it. When you click on the trashcan ICON you are talking about the trashcan as an object itself, including the programs inside it. Dave
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (02/09/91)
dtiberio@csserv1.ic.sunysb.edu (David Tiberio) writes: >In article <1659@crackers.clearpoint.com> jeff@fang.clearpoint.com (Jeffrey J. Griglack) writes: >> >>I think that the best way to improve WB 2.0 would be to release it for the >>500, 2000 and 3000. What's the holdup guys? >> >>Jeff Griglack >> >>-- >> >>Jeff Griglack | Yea, I feel terrible. I should be forced to >>jeff@fang.clearpoint.com | see "Cats" again. --From "30 Something" > > WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. TOTALLY untrue. what does the size of the kickstart have to do with the amount of chip ram? NOTHING since the kickstart will be in ROM. > >DavidTiberio SUNYStonyBrook2-3605 AMIGA TotoProductions DDDMEN UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
walt@bcarh133.uucp (Walt Sullivan) (02/09/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: > Better would be a method of including a comment with the file to > describe what interpreter to use. It can't be in the file itself > because, unlike UNIX, it's too late to standardize comment > conventions. How about putting it in the filenote? I already use my filenotes to keep information about where I got the file. I'd be REALLY UNHAPPY if, one future release, it started trying to execute an interpreter based on the contents of my filenotes. I also use filenotes to pass information around when I'm processing comp.{sources|binaries}.amiga postings. When the Amiga was first released, we were given the filenotes to use for attaching notes to files. I think Commodore would receive many flames if they tried to take back the filenote. -- Walt Sullivan BITNET: walt@BNR.CA (work) UUCP: walt@orbit.amiga.OCUnix.on.ca (home)
peter@sugar.hackercorp.com (Peter da Silva) (02/09/91)
In article <1991Feb6.032607.21986@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > I suppose this is a dir output: Yeh, I realised I'd left that out after I logged off this inadequate system. I figure anyone who would learn from this would be able to figure it out. > Would you need to segregate stuff into once per boot stuff and > once per shell stuff, or can you really do it once and for all > at the start? You better be able to do it once and for all at the start: it may not be run from a shell, remember. What if it's run from a workbench? > I do agree that this make things considerably more straightforward, > though the eventual name space or "assign" collision is bound to occur. Probably, but it's a worthwhile tradeoff. Perhaps the files should be numbered? I understand the WBstartup directory has a similar use, but I don't know as it allows scripts. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (02/09/91)
In article <1991Feb6.033356.22164@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > peter@sugar.hackercorp.com (Peter da Silva) writes: > > Better would be a method of including a comment with the file to > > describe what interpreter to use. It can't be in the file itself > > because, unlike UNIX, it's too late to standardize comment > > conventions. How about putting it in the filenote? > Probably not. The Amiga community (at least the part we see here, and who > else gets a vote? ;-) tends to ship a lot of software from system to > system, including unpacking and repacking it on various hosts. I think a > filenote would not survive this process, right? Point, but neither would a REXX bit. Perhaps we need to add filenotes to zoo/lharc/...? In any case, adding a special bit for *each* separate command language is a bad idea. I think the script bit is a mistake already. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
glmwc@marlin.jcu.edu.au (Matt Crowd) (02/09/91)
In article <1991Feb8.035953.20963@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <1991Feb4.012848.13868@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >>>How does Workbench know if you have programs running or not? >> >>You mean the Amiga resource tracking is this bad! I'm appalled. > And just what does resource tracking have to do with it? You don't need >WorkBench to run software, and in fact, any program can use the CloseWorkBench >function to *try* and close WorkBench if there are no more active WORKBENCH >LAUNCHED programs. This is what he really should have said. If you run a >program from the CLI, you may WANT WorkBench to close. And it is trivial to >have a program running that can look at the keyboard and reopen WorkBench if >a certain key is pressed. > Do you complain that your car's transmission lets you shift into >reverse while you are doing 55? Or shift from 5th to 1st at 85? Why should >the machine pretend to assume it knows best? Just because this group is comp.sys.amiga.advocacy doesn't mean you flame everybody who tries to make a comment on it. Ok, so I didn't think before I posted, and I realized afterwards that WB wouldn't be able to tell. The main point is that I have seen people boot up the machine, go through the menus and select quit. Then wonder what happened. People do NOT read manuals unless they really have to, and they shouldn't be scared of the machine. I think the machine should be very user friendly, that's what sells Macs. Power users should be able to use the CLI and config the system the way they want, but you shouldn't scare people away. C= are obviously trying with WB 2.0 to make the machine easier to use and this whole thread was intended to come up with some more suggestions. (as for the cars comment, well i'd say it won't be long before you see cars around that do stop you from doing this, if they don't exist already) >>>> 22) Can't empty trash unless trash can lid open! Stupid. >... >>If the trashcan window is selected, it should know! It checks if >>the icon is selected, not if the trash window is open and selected. > A window has nothing to do with an icon, and vice-versa. Why should >an Intuition object (the window) know anything about a WorkBench-specific >object (the icon)? That would defeat the whole point of an object-oriented >programming environment. This isn't a Mac, where selecting a window pops it >to the front. Whether the window is open or not, or selected or not is >irrelevant to whether the trashcan ICON is selected. When you have the >trashcan WINDOW selected, you are working INSIDE the trashcan. This would be >like holding your hand inside the trashcan while you are trying to empty it. >When you click on the trashcan ICON you are talking about the trashcan as >an object itself, including the programs inside it. > I don't care about this object orientated rubbish. (I still use C not C++ :-) . Think about the user not the programmer. They double click on the trashcan to see what's in it when running low on space. The window opens and has file X in it (the window is selected). They decide they don't want it, so they go up to the menu and select Empty Trash, and it doesn't work! People didn't buy 7 million Macs because they are power object orientated machines, they buy them for the software and because any idiot who knows nothing about computers can use them. C= can't do much about the software (except pay out huge sums to Microsoft etc.) but they can make the machine easy to use. It doesn't have to get in the way of people who know how to use the machine. They just need to get some people who use all types of computers to stuff around with the Amiga and see what they do and what they find hard to do. BTW, I like Macs, IBMS, Amigas and UNIX all for one reason or another. Some people in this group need to get out into the real world and use Exel on a Mac, AutoCAD Rel 11 on a 486, etc. and see that people don't buy other computers besides Amigas because they are stupid. At least not all the time :-) After seeing the others I still bought an Amiga though. > Dave Colin Adams
dtiberio@csserv1.ic.sunysb.edu (David Tiberio) (02/10/91)
In article <4058@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >dtiberio@csserv1.ic.sunysb.edu (David Tiberio) writes: >>In article <1659@crackers.clearpoint.com> jeff@fang.clearpoint.com (Jeffrey J. Griglack) writes: >>> >>>I think that the best way to improve WB 2.0 would be to release it for the >>>500, 2000 and 3000. What's the holdup guys? >>> >>>Jeff Griglack >>> >>>-- >>> >>>Jeff Griglack | Yea, I feel terrible. I should be forced to >>>jeff@fang.clearpoint.com | see "Cats" again. --From "30 Something" >> >> WB 2.0 requires 1 meg of chip ram. The kickstart in itself is about 540k. > >TOTALLY untrue. what does the size of the kickstart have to do with the >amount of chip ram? NOTHING since the kickstart will be in ROM. > >> >>DavidTiberio SUNYStonyBrook2-3605 AMIGA TotoProductions DDDMEN Okay, okay. This is about the 10th message in reply to my mistake, even after I admitted that I made a mistake. On last Sunday, I was wondering why the WB 2.0 wouldn't work on any of the machines we tested it on. I asked a friend who is an Amiga graphics artist/programmer/journalist who told me I would have needed the 1 meg chip ram. Once again, I am sorry that I posted that. Please forgive me, and please compensate my guilt with a new Amiga 3000. :) > > >UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks >ARPA: crash!orbit!pnet51!chucks@nosc.mil >INET: chucks@pnet51.orb.mn.org
The Binary Warlock (02/11/91)
>In article <1991Feb4.151637.5868@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >> $EDITOR=path/name of default editor to use >> $PAGER=path/name of pager (less,more,leggi, ppmore, etc) >> $PAINT=paint program >> $VIEW=iff picture viewer >> $PLAY=smus/med player >> $MOVIE=anim player >> $TERM=term >By this do you mean "term = terminal program", "term = what that program is >emulating", or "term = what I have plugged into my serial port"? >Suggestions: >$SHELL=preferred shell >$NAME=your full name (why not?) >$USAGE=level of help messages desired from CLI commands >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. I haven't been using my Amiga much recently what with assignments etc. but in this time I have got used to UNIX's friendliness with ENV's and that kind of thing. When I go back to my Amiga (waiting for VirusX 4.02) it would be nice to be able to specify what kind of shell I want as above in the startup without any nonsense. -- Khaos the Binary Warlock, signing off "I love my Amiga" -Anon "Ah, ~ sweet ~" -Anon "Saddam Hussein - he's worse than a Hitler, worse than a Stalin, worse than waking up wearing a wedding ring next to a Roseanne Barr who's grown a moustache. He invaded Iran. He invaded Kuwait. He even invaded parts of his own country, that's how crazy Saddam Hussein is. He's got chemical weapons filled with...with... chemicals. He's got the Bomb. We're all going to die. Details on the News at Ten." -P.J. O'Rourke in Punch.
peter@sugar.hackercorp.com (Peter da Silva) (02/11/91)
In article <18a97a8b.ARN2a78@prolix.ccadfa.cc.adfa.oz.au> dac@prolix.pub.uu.oz.au writes: > In article <1991Feb9.045752.2018@sugar.hackercorp.com>, Peter da Silva writes: > > In any case, adding a special bit for *each* separate command language is a > > bad idea. I think the script bit is a mistake already. > Explain the last sentence in that statement, Peter, and make it a > good explanation as well! Or Else. There's already an "execute" bit. A file with the execute bit set but not in Amiga load format should be treated as a script. No reason to blow another bit on the same thing. Too late *now*, of course, but why compound the mistake? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
TSPLIB@lure.latrobe.edu.au (Space Physics Library mail.....) (02/12/91)
G'day,
{Please do not reply by mail to this account, I am temporarily a guest here. I}
{offer an e-mail address that I think will work below. }
RC> rjc@geech.ai.mit.edu (Ray Cromwell) writes:
RC> ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes:
RG> dave@cs.arizona.edu (Dave P. Schaumann) writes:
DS> It would be nice to have something like environment variables for icons with
DS> standard names, so that instead of having default tool be sys:utilities/more
DS> it could be $PAGER (or whatever syntax you like), and then if I *want* to
DS> [...]
DS> Surely this would be an easy thing to do.
I can't believe it! One of the points I've been wanting/waiting to raise in
comp.sys.amiga.advocacy at my home site (which I'm hoping will pick the news
group up) has been raised in my absence. Way to go Dave! :-)
RG> Absolutely great idea, Dave! And if the environmental variable wasn't set
RG> you could have the default be the default tool. Give this man a job, C=.
Can I have one too then C= ? I mean, I've had the exact same idea. :-) But
seriously we have a convergence of users wills here because we know of three
of us (at least) that would like this feature.
RG> Additionally, whenever the system can't find either the environmental
RG> variable or the default tool, have a requester inform the user of this
RG> fact and ask him if he would like to help find it. Then up pops a file
RG> requester a la AmigaVision, with which the user sets the path. (excuse
RG> me if this has been covered before, I've missed much of this thread).
RG>
RG> Regards,
RG> Richard
RG> gerber@rigel.astro.uiuc.edu
Give Richard a job too C=.
RC> PROPOSAL:
RC>
RC> Why don't we all particpate in developing some standard Environment
RC> variables for applications to use. Then future updates and new programs
RC> [...good user's eye justification deleted per bandwidth considerations...]
RC> I'll start it off..
RC>
RC> $EDITOR=path/name of default editor to use
RC> $PAGER=path/name of pager (less,more,leggi, ppmore, etc)
RC> $PAINT=paint program
RC> $VIEW=iff picture viewer
RC> $PLAY=smus/med player
RC> $MOVIE=anim player
RC> $TERM=term
Let us stick with this terminology until/if someone points out objections to
it...
$SHELL= the name of the CLI shell you wish to be invoked...if a program has
a CLI window option say (perhaps $CLI?). {With popup shells I can't
see this as a much needed option.}
$SCREEN= with public screens in OS 2 perhaps the user would wish to select a
screen for apps to come up on(say a TermBench screen where terminal
emulators could popup?)
RC> What are the benifits of env vars? How many times has a program assumed
RC> the path of a program. Like a picture file looking for 'myhd:picviewer' ?
RC> Of course you have to edit it with the info command.
This was the same set of events that led me to thinking I should propose it.
RC> With env vars, the Icon can just execute '$VIEW'. Optionally you could even
RC> specify your favorite command line options. One problem with this is,
RC> neither WB nor AmigaShell support wildcard expansion. Until Commodore adds
RC> env var support in icons, it will have to be hacked with an iconx script.
RC> The tooltype of pictures/music/textfiles, etc would have to execute
RC> s:envexpand which would GetEnv the var and execute it.
I may actually give this a go. I like the concept, hmmm. :-)
RC> Any ideas?
{Not regarding the Env vars for WB.}
These ideas fall into the category of `Workbench should be an equally powerful
alternative to a CLI/Shell' no? {At least they do for me IMHO. :-)}
A complicated (and I realise unoriginal) idea I've been `Blue Skying' with is
the notion of alternate(user defined) viewing of the file space directory tree.
You want that in English you say? Okay :-), but I'll use an example.
Ocassionally, I find myself wanting to consider all of the files I am working
with (that come from different sub-directories/volumes) as part of 1 temporary
directory structure. Isn't this idea that of linking directories to appear as
one super directory?
Well yes it is and all I really want is a way to do it from WorkBench... :-)
I don't mean this should be permanent unless the user wants it. I also realise
that some criticisms will be that this is merely wishing for featurism. I can
admit that you can do without this feature for WorkBench but I'd rather have a
WorkBench environment that has a `look' reflecting the logical structure of an
environment that could be setup via a CLI. {Philosophy mode off now. :-)}
{Is this is already possible in AmigaDOS2.x with directories if they are link}
{-ed together, and have a .info icon for WorkBench to see? }
yours truly,
Lou Cavallo (e-mail: U3364521.ucsvc.ucs.unimelb.edu.au, I think)
PS: I'm sorry about the length of this posting. I've tried to be as brief I
can and I hope the clarity of my writing hasn't suffered.gblock@csd4.csd.uwm.edu (Gregory R Block) (02/12/91)
From article <1991Feb11.113601.1338@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): > In article <18a97a8b.ARN2a78@prolix.ccadfa.cc.adfa.oz.au> dac@prolix.pub.uu.oz.au writes: >> In article <1991Feb9.045752.2018@sugar.hackercorp.com>, Peter da Silva writes: >> > In any case, adding a special bit for *each* separate command language is a >> > bad idea. I think the script bit is a mistake already. > >> Explain the last sentence in that statement, Peter, and make it a >> good explanation as well! Or Else. > > There's already an "execute" bit. A file with the execute bit set but not in > Amiga load format should be treated as a script. No reason to blow another > bit on the same thing. Too late *now*, of course, but why compound the mistake? > -- > Peter da Silva. `-_-' > <peter@sugar.hackercorp.com>. Well..... Not necessarily. If not loadable, and execute not set, it's a script, yes. Fine. If execute set, make it a script that runs like a command. But set the SCRIPT bit if you'd like to make it an AREXX script. See, what if it isn't loadable, and execute isn't set? It could be a normal text file... so maybe set the environment variable $pager (I seem to love that idea...), and have it automatically page things that aren't loadable, and without execute set ... Anyways. That's jumping WAY ahead, and borders on excessive chumminess and being littlemore than a pain... But anyways... I think that the script bit already exists, but isn't being currently used. It sounds like a brilliant use for it to me... Script for Arexx, Execute for standard scripting, and none set for standard text file... I like it the more I think of it... :) Take a rest, peter... If you don't like the feature, don't use it. You can type "execute xxx", and "rx xxxx" if you like... Personally, I'd like it... And I think it would reduce the fear of the "dreaded cli"... Would make it much easier to do... Just remember to give a good explanation of each bit in the manual.... :} ------------------------------------------------------------------------------ gblock@csd4.csd.uwm.edu | Amigas, amigas, everywhere, but not a one can think. ------------------------------------------------------------------------------
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (02/13/91)
>From article <1991Feb11.113601.1338@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): >>There's already an "execute" bit. A file with the execute bit set but not >>in Amiga load format should be treated as a script. No reason to blow >>another bit on the same thing. Too late *now*, of course, but why compound >>the mistake? In article <9474@uwm.edu> gblock@csd4.csd.uwm.edu writes: >> Well..... Not necessarily. If not loadable, and execute not set, it's a >>script, yes. Fine. If execute set, make it a script that runs like a >>command. But set the SCRIPT bit if you'd like to make it an AREXX script. But what do you do when (suppose) Commodore decides that AmigaBASIC programs can also be executed from the CLI by typing their names? Add another "AmigaBasic" bit?? Peter is making a good point. On UNIX, there is only 1 bit for this (execute). If the file is a text file, it is automatically fed to an interpreter program. By default, the interpreter is the shell (specifically the Bourne Shell), but you can make it ANY interprer by specifying the name of the interpreter as the first line of the file. Commodore's idea is a compromise between your and Peter/UNIX's. The execute bit is for binary executables. The script bit is for CLI scripts and AREXX scripts. (The Shell figures out whether the file is a CLI or AREXX script.) Commodore can add more interpreters later, but it involves changing the shell to add one. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
greg@travis.cica.indiana.edu (Gregory TRAVIS) (02/13/91)
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > Peter is making a good point. On UNIX, there is only 1 bit for this >(execute). If the file is a text file, it is automatically fed to an >interpreter program. By default, the interpreter is the shell (specifically >the Bourne Shell), but you can make it ANY interprer by specifying the name >of the interpreter as the first line of the file. Just want to clarify the mechanism by which a file is determined to be a script under UNIX: The shell first tries to "exec" the file - meaning it hands it to the Kernel for execution as a binary file without ever looking at it. The Kernel then reads the header and if it doesn't find a magic number in the header that indicates the file is executable it returns on the exec and sets an error. The shell then says "Hmm, maybe it's a script" and reads it (looking for that #! /bin/xxx if it's in there). Some (most) Kernels incorporate a (aesthetically horrible) efficiency hack in that the Kernel looks for the "#!" characters and, if it finds them, executes the named shell with the script filename as argument instead of just failing the exec. -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.indiana.edu Center for Innovative Computer Applications This signature intentionally left blank.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (02/13/91)
In article <7553@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: >>From article <1991Feb11.113601.1338@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): > >>>There's already an "execute" bit. A file with the execute bit set but not >>>in Amiga load format should be treated as a script. No reason to blow >>>another bit on the same thing. Too late *now*, of course, but why compound >>>the mistake? > >In article <9474@uwm.edu> gblock@csd4.csd.uwm.edu writes: >>> Well..... Not necessarily. If not loadable, and execute not set, it's a >>>script, yes. Fine. If execute set, make it a script that runs like a >>>command. But set the SCRIPT bit if you'd like to make it an AREXX script. > > But what do you do when (suppose) Commodore decides that AmigaBASIC >programs can also be executed from the CLI by typing their names? Add >another "AmigaBasic" bit?? ^^^^^^^^^^ Ah, you said the AB word :-). There comes another idea to my mind: How could we give CLI/Shell the ability to evaluate the .info files? Just type in the name of a project file, the system finds that this is not an executable binary, and now (new!) looks for existance of a .info file. If present, the default tool is gotten from this file, the tool and project loaded as if started from WB. How about this enhancement to Shell? Would it mean big overhead? I think, one even wouldn't need another signal bit (if yes, then how about p for project). -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
davewt@NCoast.ORG (David Wright) (02/14/91)
In article <1991Feb9.052424.214@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >(as for the cars comment, well i'd say it won't be long before >you see cars around that do stop you from doing this, if they >don't exist already) They do, it's called an automatic transmission. BUt the problem is just what it the right situation for the machine to decide? Best economy? Best performance? I can easily envision a car with two computer chips, one with settings for performance, and one with settings for economy that let you switch between them at the touch of a button. The first thing I have always done since GM (and Ford) started putting a data chip in their vehicles is to replace the chip with one designed to produce more power at the cost of fuel efficiency. My complaint about your complaint is that I don't think that the machine should ever try and out think what the human wants to do, as human being are ittational, and may want to do things (intentionally) that are not logical. Until machines are like HAL, and can be overidden to the extreme, they should mind their place and interfere as much as possible with what users want to do, even if it is a stupid action (Maybe a confirm requester when the "Quit" option is selected? (But NOT when the CloseWorkBench() call is made, since obviously there is some other program running to be able to make the call). > >I don't care about this object orientated rubbish. (I still use >C not C++ :-) . Think about the user not the programmer. They double ^^^^^^^^^^ >click on the trashcan to see what's in it when running low on space. ^^^^^^^^^^^^^^^^^^^^ >The window opens and has file X in it (the window is selected). They >decide they don't want it, so they go up to the menu and select >Empty Trash, and it doesn't work! People didn't buy 7 million Macs Yes it does! Think about what you said! If they have doubleclicked on the trashcan Icon, the icon will be selected, and the window will be opened (if it wasn't already) so they can see what is inside. If they then select the "Empty Trash" option, all the icons in the trash can will be deleted, as expected. >Empty Trash, and it doesn't work! People didn't buy 7 million Macs >because they are power object orientated machines, they buy them >for the software and because any idiot who knows nothing about computers >can use them. C= can't do much about the software (except pay out >huge sums to Microsoft etc.) but they can make the machine easy to Ugh. I hope I never see another Microsoft product on my Amiga again. Using AmigaBASIC on my old 1000 was bad enough. Having to use MS-DOS at work occasionally is too much. >not all the time :-) After seeing the others I still bought an Amiga >though. Hurray! You made the right (and intelligent :-) choice! Dave
david@twg.com (David S. Herron) (02/19/91)
In article <9474@uwm.edu> gblock@csd4.csd.uwm.edu writes: >From article <1991Feb11.113601.1338@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): >.. Script for Arexx, Execute for standard scripting, and >none set for standard text file... I like it the more I think of it... :) >Take a rest, peter... If you don't like the feature, don't use it. You can >type "execute xxx", and "rx xxxx" if you like... BZZZT!! there's a lot more interpreters (potentially anyway) out there than just "execute" and "rexx". BSD Unix (and now SysVr4 assumably) have had for, a long time, a way of specifying within the file what interpreter to use. For exec(2) on a file which had the "execute" bit turned on and is not a normal object file the first line is read and examined to see if it is like so: #! /path/interpreter args And if so, then /path/interpreter is executed with the file on its stdin. Methinks this is the sort of capability that Peter is wishing for. An odd example that might not occur immediately to you is: #! /bin/egrep ^[^#] some text lines like the following are comments: # this is a comment some more text Which is what I used once long ago for the "pizza" program -- a telephone number of local food places the program which listed the dialup phone numbers for the system At my old job at ms.uky.edu. (Aside: this runs the file through egrep, which is instructed to pass on all lines which do not start with '#'..) (Version 1 of this example used "#! /bin/cat" .. ;-) Another example: perl is available on AmigaDOS. On a BSD Unix machine, to have a perl script executable one simply puts "#! /usr/local/bin/perl" at the head of the file. On AmigaDOS there isn't any way to do this.. so perl programs become second-class citizens in that you have to remember what interpreter to use on the script. Which brings up another point. Why should one have to remember which language an executable script is written in in order to execute it? When running compiled programs one doesn't have to know whether it was written in FORTRAN or C, one just runs it. Why should it be any different for executable scripts? As for how to indicate which interpreter to use: The BSD Unix method is pretty darn good but some of you Anti-Unix puritans might not like it. An advantage of putting it into the file like this is that when you edit the file you know right away which interpreter it is. There is a small problem of backwards compatibility with AREXX scripts. That is, there is/was a convention that you start 'em with "/* comment */" so that WShell will recognize that it's an AREXX script. There was a similar "flag day" when BSD Unix added the executable script support, and somehow we made it out of that thicket alive. ;-) Therefore I really think this is a non-problem .. David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- MS-DOS ... The ultimate computer virus.
farren@sat.com (Michael J. Farren) (02/24/91)
david@twg.com writes: [on UNIX methods of doing scripts] >the first line is read and examined to see if it is like so: > > #! /path/interpreter args > >And if so, then /path/interpreter is executed with the file on its stdin. >[...] >There is a small problem of backwards compatibility with AREXX scripts. >That is, there is/was a convention that you start 'em with "/* comment */" So where's the problem? You just look for the following, in order: 1. Does it start with a "/* ... */" comment? If so, run it under AREXX, if possible. If not, abort. 2. Does it start with the UNIX standard "#! <filename>" comment line? If so, execute <filename> <this script as argument>. If anything goes wrong, abort. 3. If it doesn't start with either one, try it as a standard AmigaDOS script. I don't see why all alternatives can't be comprehended in this fashion. -- +-----------------------------------------------------------------------+ | Michael J. Farren farren@sat.com | | He's moody, but he's cute. | +-----------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (02/28/91)
In article <1991Feb23.203358.27835@sat.com> farren@sat.com (Michael J. Farren) writes: > 2. Does it start with the UNIX standard "#! <filename>" comment line? > If so, execute <filename> <this script as argument>. If anything > goes wrong, abort. What do you do about programs that interpret scripts, but use something other than "#" for a comment leadin? That's the point... AREXX is already an exception to this, and there will undoubtedly be others. Why not define things more generally in the first place: 1. If the script contains "#!text anwhere in the first line, possibly terminated with "!#", then the text and path to this file is prepended to the command line and it is reparsed. So you can handle FrobProc scripts (that use the ADA convention), SuperShell scripts (that follow the Shell comment convention) and so on... -- #!frobproc ; #!supershell /* #!AREXX!# */ ... But look for the same string in the comment field first, so you can use that to call the script without having to load the file. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) (03/02/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: < farren@sat.com (Michael J. Farren) writes: < > 2. Does it start with the UNIX standard "#! <filename>" comment line? < > If so, execute <filename> <this script as argument>. If anything < > goes wrong, abort. < < What do you do about programs that interpret scripts, but use something < other than "#" for a comment leadin? That's the point... AREXX is already < an exception to this, and there will undoubtedly be others. Why not define < things more generally in the first place: < < 1. If the script contains "#!text anwhere in the first line, possibly < terminated with "!#", then the text and path to this file is < prepended to the command line and it is reparsed. < < So you can handle FrobProc scripts (that use the ADA convention), SuperShell < scripts (that follow the Shell comment convention) and so on... < < -- #!frobproc < ; #!supershell < /* #!AREXX!# */ < ... Wouldn't it be better to enforce a rule that the "!<filename>[!]" MUST immediately follow the leading comment character(s)? Also, it seems unnecessary to keep the "#" as part of the requirement. Simply do it as follows: --!frobproc ;!supershell /*!AREXX! */ After all, even under the UNIX convention, the "#" is only there because it is the accepted comment character for the shell. It's the "!<filename>" that is important. Regards, Chris -- Chris (Insert phrase here) Seaman | /o -- -- -- cseaman@gateway.sequent.com <or> ||| -- -- - I'm Outta Here, Man! ...!uunet!sequent!cseaman |vvvv/ -- -- - The Home of the Killer Smiley |___/ -- -- --
peter@sugar.hackercorp.com (Peter da Silva) (03/02/91)
In article <54303@sequent.UUCP> cseaman@sequent.UUCP (Chris "The Bartman" Seaman) writes: > Wouldn't it be better to enforce a rule that the "!<filename>[!]" MUST > immediately follow the leading comment character(s)? What does that buy you? The shell, remember, doesn't know a comment character from a hole in the ground. This means the shell still has to know all sorts of special cases... or it'll execute files like this: +---------- |Remarkable! I have found a proof... ... You can't disallow ascii text as comment characters, because there have been languages that used that sort of convention: +---------- |REM !BASIC! This is a program... ... You can't even disallow whitespace: +---------- |( !Forth! requires the comment leadin be a separate word ) ... > Also, it seems > unnecessary to keep the "#" as part of the requirement. I was using #! as an example. It could be any unique string: +---------- |/* @@command=AREXX@stack=10000@window=CON:0/0/640/200/BARTMAN@ */ ... In this case "@@" is the leadin. > After all, even under the UNIX convention, the "#" is only there because it > is the accepted comment character for the shell. It's the "!<filename>" > that is important. Well that might be the historical reasoning, but the string "#!" is actually handled as a 16-bit magic number. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
gblock@csd4.csd.uwm.edu (Gregory R Block) (03/03/91)
From article <peter.667967011@cutmcvax.cs.curtin.edu.au>, by peter@cutmcvax.cs.curtin.edu.au (Peter Wemm): > filenote fred.rexx "SHELL=rx %s" > Crazy? Perhaps not.... I think not. I use my filenotes for personal use. I find them invaluable. I will not give them up. Not without a fight, anyways. -- gblock@csd4.csd.uwm.edu | Amigas, Amigas everywhere, but not a one can think. ----Gregory R Block---- | Where's an AI when you need one? ________________________| A Mac, by any other name, would smell like a lawsuit Roses are red, Violets are blue: Go buy a Mac, and you'll be screwed too...
peter@cutmcvax.cs.curtin.edu.au (Peter Wemm) (03/03/91)
A Simple idea: Why not use the comment as a specifier? something like filenote fred.rexx "SHELL=rx %s" The shell would see the 'SHELL=' in the comment and substitute in the name and call "rx fred.rexx" Crazy? Perhaps not.... -Peter -- Peter Wemm ------------------------------------------------------------------------------ peter@cutmcvax.cs.curtin.edu.au (if fails, try peter@cutmcvax.oz.au)