MCARTSHA@UREGINA1.BITNET (Shan Mcarthur) (03/15/89)
I like the smoothing function on WB 1.3. How 'bout adding another type of smoothing in WB1.4: have two types of smoothing, one linear smoothing (joining two points with a staight line) and one curve smoothing (joining two poits with the best possibe curve taking into account more than just the two points). It would be the greatest for font printouts; they would appear less blocky. Shan
usenet@cps3xx.UUCP (Usenet file owner) (03/16/89)
An option should be provided when mounting NEWCON: to have it put scroll bar(s) on its window. You should be able to say that the window is #rows by #cols. This gives text history, and keeps lines from wrapping around when the window is small. To make history usefull there should be a way to cut and paste; cut and paste should use clipboards so that other things can pull in text from a console window. None of this is very hard to do, so why not? -- Joe jap@syssun.cl.msu.edu In Real Life: Joe Porkka porkka@frith.egr.msu jap@syssun.cl.msu.edu (35.8.1.1) Life is just a game, so relax and be happy.
jimm@amiga.UUCP (Jim Mackraz) (03/16/89)
In article <2214@cps3xx.UUCP> porkka@frith.UUCP (Joseph A Porkka) writes:
)An option should be provided when mounting NEWCON: to have it put
)scroll bar(s) on its window. You should be able to say that
)the window is #rows by #cols. This gives text history, and keeps lines
)from wrapping around when the window is small.
)To make history usefull there should be a way to cut and paste; cut and
)paste should use clipboards so that other things can pull in text from
)a console window.
Good suggestions. Not new, but good.
)None of this is very hard to do, so why not?
I'm glad to hear that. Why don't you just whip it out so we can see
how everyone likes it? Don't worry about size, we'll be downcoding
it to hand-optimized hex machine code later.
) -- Joe
) Life is just a game, so relax and be happy.
Enjoy, college, buddy. Things get a little more real later on. Learn lots.
Be sure to get a 4.0, it's pretty easy. Lots of other guys did.
jimm (former professional student and (current?) wise-ass)
--
Jim Mackraz, I and I Computing "Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition."
- Gang of Four
Opinions are my own. Comments are not to be taken as Commodore official policy.paolucci@snll-arpagw.UUCP (Sam Paolucci) (03/16/89)
About allowing for redirection (<,>,>>) to be anywhere on the command line? -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
richard@gryphon.COM (Richard Sexton) (03/17/89)
In article <3654@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: > > In article <2214@cps3xx.UUCP> porkka@frith.UUCP (Joseph A Porkka) writes: > )An option should be provided when mounting NEWCON: to have it put > )scroll bar(s) on its window. You should be able to say that > )the window is #rows by #cols. This gives text history, and keeps lines > )from wrapping around when the window is small. > )To make history usefull there should be a way to cut and paste; cut and > )paste should use clipboards so that other things can pull in text from > )a console window. > >Good suggestions. Not new, but good. > > )None of this is very hard to do, so why not? > >I'm glad to hear that. Why don't you just whip it out so we can see >how everyone likes it? Don't worry about size, we'll be downcoding >it to hand-optimized hex machine code later. Yes, and as long you are making AmigaDOS look like Apollo Aegis, don't forget to add the transparent networking file system. -- ``Quick Robin ! The Bat-Listings !'' richard@gryphon.COM decwrl!gryphon!richard gryphon!richard@elroy.jpl.NASA.GOV
rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (03/18/89)
How about customizable editing for the shell, supporting various types of cursor movement (ie forward word, back word, begining of line, end of line etc.). Also some way to copy text from window to window (ala snipit), possibly using the clipboard device. Scroll bars for shell windows would be VERY nice. Using ARP (or just making the commands smaller [ie dir is almost 9K, list is almost 10K ]) would also be an improvement, as the c: directory is getting to be of massive proportions. +----------------------------------------------------------------------------+ | Disclaimer: Me? Post That, impossible I never post anything... | | TypetoYouLater(Everyone); --> "functional Good bye".... | | Rick Golembiewski [ Pronunciation is half the Battle, spelling the other] | +----------------------------------------------------------------------------+
C503719@umcvmb.missouri.edu (Baird McIntosh) (04/03/89)
I have seen many suggestions about what 1.4 should have, but here are a
few I don't remember seeing:
1) Multitask the Workbench! Why couldn't the Workbench launch a separate
process to display a disk or directory's contents? Sometimes I open a
directory and decide I don't want to see it, but I am forced to wait
for all of the .info files to load and be displayed as icons before
I am allowed to close the window...I want to open it/close it anytime.
I never wanna see that ZZ cloud again. Note: I am not sure how this
would work for launching programs, but for directories and such, it
shouldn't be hard -- right?
2) Is there a bug with the abort of ICONX? Ctrl-C does not exit an
ICONX program...isn't it supposed to?
3) Implement something like HandiIcons to allow programs and CLI-scripts
(with the script bit set) to be run from a menu on Workbench. The
user could customize an added menu to have the names of his
favorite 20 (40? with interlace) programs selectable without the
bother of rooting through all of those directory windows.
Well, there are some ideas...will any of them show up in 1.4?
Baird McIntosh
==)=))==)))===))))====)))))=====))))))======)))))))=======Amiga!!!======
disclaimer: if it don't offend YOU, send me email & I'll try again. ;-)
BITNET: c503719@umcvmb.bitnet <or> INTERNET: c503719@umcvmb.missouri.edu
"IBM -- it BORES me...Macintosh -- how 'bout the PRICE of them apples!"
======Amiga!!!=======(((((((======((((((=====(((((====((((===(((==((=(==840445m@aucs.UUCP (Mic Mac) (04/09/89)
Here is my entry for the 1.4 wish list. It is nothing very big and should only require a few hundred bytes of code. Oh wait ... this is Commodore ... make that a few K of code :-) (please, no flames) I have been doing a lot of file and directory copying lately. I have been rounding up all the stuff on my fish disks that is usefull and collecting them onto disks. Sometimes there are four or five directories on one Fish disk that all should go to the same disk. So I merely highlight them all and drag them all to the other disk ... no problem. Unless of course there is no room on the other disk, then you end up with partial directories with no icons, so you have to go into the CLI (which some people don't know how to use) to get rid of the directory. To solve this problem, Commodore could do 1 of 2 things: (1) Make a quick check to see how much space is occupied by the directories you want to use. Compare this with the amount of space left on the destination drive. If there is not enough space, tell the user and abort the operation. (2) A better way would be as follows. After the directory is made on the new disk, the first file to be copied should be the #?.info file. Now the user can just drag it into the trashcan if there was not enough room for the thing. Now, how, you ask, does the user know which drawer was the one that was being copied when the disk became full? Very simple. When multiple drawers are selected to be copied, they all show their alternate image (selected state). As a drawer (or any file for that matter) is copied, it should automatically become unselected on the Workbench. Then if a person were copying a number of files or drawers, and the destination disk become full, he would know which files were not copied by simply examining which icons were still in the selected state. Voila ... problem solved. -- % Alan W. McKay % % % Acadia University % " The world needs more Socrates % % Wolfville N.S. % walking the streets today " % % CANADA % - S. Corbett %
ugkamins@sunybcs.uucp (John Kaminski) (04/10/89)
My 1.4 wish list: Although I know it would be rather incompatible with the previous shell, it would be SOOOOOOOOO handy for the shell to centralize filename expansion, i.e., wildcarding, and modify the standard programs (copy, more, rename, delete, etc.) to accept multiple arguments and act upon each. Or how about the Pr1me "shell" (it is called the "command level" on their machines) solution? The Prime simply re-invokes the command several times, sub- stituting the next filename on each invocation. UNIX ln(1) link(2) and unlink(2) (For the non-UNIX types here, the ( # ) notation is the standard manual section) would be appreciated and seemingly rather easy to implement. As I put in a recent posting (indirectly), it would be convenient to store the shell script program under both "co" and "execute." ln(1) is the shell-level command which calls link(2). link(2) will create another directory entry which points to the same data as another directory entry. unlink(2) undoes link(2), and the modification needed is to store the current number of references to the file so that unlink() will release the disk storage if the directory entry being unlink()ed has a reference/link count of 1. Have a reflexive directory entry such as UNIX's "." (heck, you have ".." -- that is the same as "/"). It would help typing in Copy commands among other things. Copy shouldn't complain about something like copy df0: all to nil: Have all the defined file bits work. I don't understand it, but I could swear I protected a file against reading, but cat --- um hee hee! ahem... excuse my UNIXness -- Type still gave me the file. Real pipes. PIPE: is a good start, but there's nothing quite like: $ who | grep '^anyuser' | tail # last 10 listings of anyuser logged in RunBack standard. Execute() should *N*O*T* have to access C:Run (why does it in the first place?) What's wrong with just loading and running as a child process, like system(3) on UNIX? Or just permanently put it in the OS, it's only all of 2324 bytes long as an executable file. I'm sure there's others, but I'm too tired to remember them.
jdow@gryphon.COM (J. Dow) (04/11/89)
I have a rather simple request that may not be possible to implement at this
time due to hardware limitations. (But I sure would appreciate a best guess
approach...)
I am running some fairly large to humongous harddisks here at the Wizardess'
Abode. The bitmaps take substantial amounts of ram. A disk with 700megabytes
of available storage takes some 341k for just the bitmap alone. If I add some
buffers to handle one cylinder worth of data I eat another 407k of storage.
It has occurred to me that two such monsters and I have eaten almost all my
2megabytes of 32 bit ram. It also occurs to me that RAM: eats the rest rather
quickly.
PLEASE alter the behavior of the filesystem and the ram handler so that they
store from the TOP end of ram address space down. RAM: can go ANYWHERE at all
in the memory map (with a preference to avoid CHIP or course.) THe disk bitmaps
and buffers want to be in DMAable FAST ram with a preference for the top of
the range specified by the "MASK = " parameter.
This will preserve my VERY precious 32 bit FAST ram space for use by live
programs instead of inconsequential matters (for speed purposes) such as
disk buffers and bitmaps. It will have a secondary salutary effect of making
it substantially LESS likely that the bitmap storage will get creamed by
runaway programs. (And on a 300 meg drive partition this is no inconsequential
event, trust me!)
--
Sometimes a bird in the hand leaves a sticky deposit.
Perhaps it were best it remain there in the bush with the other one.
{@_@}
jdow@bix (where else?) Sometimes the dragon wins. Sometimes
jdow@gryphon.CTS.COM the knight. Does the fair maiden ever
{backbone}!gryphon!jdow win? Surely both the knight and dragon
stink. Maybe the maiden should suicide?
Better yet - she should get an Amiga and
quit playing with dragons and knights.richard@gryphon.COM (Richard Sexton) (04/11/89)
[Jdows stuff about bitmaps deleted]
As long as we are talking about main memory utilization for
hard drives, I have an observation.
Now, note that what information I have is second hand, and none
of it may be accurate.
I understand that every mounted partition uses 32K or chip RAM.
(Nota again that I use supramount, not a mountlist. I'm lazy)
I understand that this is for track buffering.
Well, 96K is still a lot of memory, for us poor slobs
with ``only 1 megabyte'' (did I really say that ?)
so I'd be more than willing to let them share a single
track buffer. I'd certainly be willing to trade off the
performence loss to get the memory back.
--
``Parents who have children, have children who have children''
richard@gryphon.COM decwrl!gryphon!richard gryphon!richard@elroy.jpl.NASA.GOVdaveegan@dhw68k.cts.com (Dave Egan) (06/19/89)
Ok here's another *silly?* suggestion for the 1.4 version of the Amiga OS
When the system GURU's, instead of showing the flashing box and numbers,
why not display a Nuclear Mushroom cloud? Then you know FOR SURE that things
have really gone bad (Ok, so you do with GURU also..) but what a great thing
to show friends! ..... Returning you back to reality...
--
Dave Egan
uucp: ...{spsd,zardoz,felix}!dhw68k!daveegan
InterNet: daveegan@dhw68k.cts.com