kent@swrinde.nde.swri.edu (Kent D. Polk) (03/22/89)
Here is my 1.4 wish list: (As if anyone wants to know) Some of these things could be provided outside of Commodore, but official, consistent support would be nice. -------------------------------------------------------- 1) A 'CON:' with : a) Text memory buffer of user-definable size. b) A scroll gadget for accessing the above. c) Builtin clipboard support. Maybe just support text. Maybe just ascii text that is font independent. d) Redirect output of clipboard (or buffer or displayed part of buffer) using mouse at least. e) Be able to turn these features off or use two different 'CON:'s (Like Sun's Command Tool and Shell Tool) 2) Expanded text/graphic dump/print capabilities. a) Add support to Dump a specific window. b) Dump text window in text or graphic modes. (Support text or graphicmode dumps of the info in 1.d also) c) Allow printing of text in graphic mode using a specified font. Kinda like Enscript on the Suns. (This could be a something significant). d) Builtin CMD support. e) Menu/requestor oriented operation for this stuff. 3) Sockets (pipes). Dup filedescriptors. Not just for a shell (be nice), but for launching your own stuff. Makes simulations/debugging, other stuff much easier. 4) Wildcards & Shells (here we go): a) Don't require support for wildcards in programs. I hear that there will be better support for shells in 1.4. Let the shells determine how to expand wildcards. Thus, if you want traditional AmigaDos wildcards, use the shell which comes with the Amiga, which would expand wildcards & send them to the program. If you want Unix-style wildcards, get a csh/korn/whateversh shell to do it just the way you want. b) Handle redirection in the shell. Anywhere on the command line. (like Unix - ...oops) c) allow shells to run on top of either a 'Command Tool' type CON: or a 'Shell Tool' type Con:. Let the user decide which to use. d) Shell Environment Variable (which shell to default to). ----- 5) Support input redirection & multiple filenames in ALL supported CLI programs, Please. a) SORT: Come on, how often do you sort a file? Ok, PIPE: can work here, but... b) MORE: Why not support multiple filenames? Ok, I have this shell alias which foreaches all the filenames, but ... I can't quit once for all, and I can't backup. 6) Real Support for > 640 * 200 displays - OK, this is my pet peeve. I work in hires interlaced all day long. A 50 * 80+ window is just too good to give up, however... you ought to hear the comments here at work about the crummy washed-out colors I have to set to use these things (A500 at work, A1000 at home). It gives the Amiga a bad name, but I ain't gonna give up big windows just so's my display looks pretty. And, nope I can't get an A2000 and a flicker-fixer. ($!*@#$!@!$) ----------------------------------------------------------------- Ok, I really like my Amiga. Fix these things & were on our way to a real, competetive workstation. Just speeding things up doesn't make it a workstation. Look at the 386 PCs. I sure wouldn't call any of them workstations when they are running MS-DOS. (Hey, maybe I oughta send this stuff to Max Toy!) Thanks, Kent Polk (Representing little green tree frogs being chased by dogs) P.S. Thanks for the recent KeyMapEd. Now I have a repeatable Return key for working in vi! (More changes to follow).
usenet@cps3xx.UUCP (Usenet file owner) (03/25/89)
In article <12104@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk) writes: > >1) A 'CON:' with : > a) Text memory buffer of user-definable size. > b) A scroll gadget for accessing the above. > c) Builtin clipboard support. > Maybe just support text. > Maybe just ascii text that is font independent. > d) Redirect output of clipboard (or buffer or displayed part of buffer) > using mouse at least. > e) Be able to turn these features off or use two different 'CON:'s > (Like Sun's Command Tool and Shell Tool) I have been working on the design for the above. It would include a menu that allows you to select which options you want, and allow expanding the menu for extras that you think of. It would also support some environment variables for selecting options by default. ***** ** **** A problem I have not yet figured out, how does the normal console.device connect itselft to a window???? From my humble experiments, it does not appear to change the Window structure. Setting the RAWKEY IDCMPFlag keeps the console from getting anykeyboard info though.... Any help anybody? > ... stuff deleted >3) Sockets (pipes). Dup filedescriptors. > > Not just for a shell (be nice), but for launching your own stuff. > Makes simulations/debugging, other stuff much easier. Easily done with MsgPort's and Messages, any they are *much* lower on overhead. With carefull placement of Forbid()/Permit() you can be sure that the MsgPort won't dissapear before you send a message, and you can be sure you won't get any messages before you remove the port. Please anybody send info about how the console.device attaches itself to a window. Even if it will break in 1.4, I promise I won't tell anybody else how its done. 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.
jesup@cbmvax.UUCP (Randell Jesup) (03/25/89)
In article <2273@cps3xx.UUCP> porkka@frith.UUCP (Joseph A Porkka) writes: >**** A problem I have not yet figured out, how does the normal >console.device connect itselft to a window???? > >From my humble experiments, it does not appear to change the Window >structure. Setting the RAWKEY IDCMPFlag keeps the console from >getting anykeyboard info though.... It gets input from being in the input.device stream, below intuition. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
andy@cbmvax.UUCP (Andy Finkel) (03/30/89)
In article <2273@cps3xx.UUCP> porkka@frith.UUCP (Joseph A Porkka) writes: >In article <12104@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk) writes: >I have been working on the design for the above. It would include a menu >that allows you to select which options you want, and allow expanding >the menu for extras that you think of. make your menus optional. Otherwise, programs that already have menus will have some problems. Remember, the program thinks the window belongs to it. >Please anybody send info about how the console.device attaches >itself to a window. I can send you a code example...its also on Fish disk 38 -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Give me a Standard large enough, and a Committee to discuss it, and I will prevent the Earth from moving." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.