peter@sugar.UUCP (06/10/87)
I'm sure most of this has already been discussed, but I'd like to toss out my Amiga Wish List. Be warned that several suggestions here have led to massive flames on CI$. I hope this forum has a more enlightened readership. 1) Put file names in directories. It seems totally bizzarre to me that a machine with a user interface (Intuition/Workbench) that had to repeatedly scan directories should have directories that are so slow to scan. This could be implemented in a backwards-compatible fashion by (for instance) provoding a seperate fork for the file names. A better way would be a whole new disk type. The new system should of course be able to read old disks. If the directory has fewer than some 140 entries this will be at least as fast, since 140 entries at 30 characters each (plus a few bytes of overhead) will fit in a 5K disk track. 2) Have the workbench display all files. This would obviate the need for stopgaps like DoTil and DirUtil. 3) Put a pointer to the .info file in the Comment field of the file, so that your directories (for example) can share icons. 4) A new CON: device that uses a simple-refresh window, keeps track of 24 lines by 80 columns of text, and has scroll bars to pan a full size screen in the window. I have implemented part of this as an excersize, and it's way faster and more memory efficient than smart-refresh ones. 5) Sizing and dragging windows shouldn't lock layers, instead they should use sprites to indicate the corners (a-la the HP Integral). 6) Allow an image to underly the workbench, ala the Xerox Star's "Mount Fuji". 7) It would be nice if uw could be made to work with System V shell layers. I understand it only works with BSD job control. 8) There should be an unettended mode, where all requestors automatically return failure. This would allow the machine to reliably run a BBS or operate as a SCADA master-station. 9) Could someone post the missing information from the AutoDocs? I bought 1.2 and can't use the new intuition calls because I don't have them.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/12/87)
>8) There should be an unettended mode, where all requestors automatically >return failure. This would allow the machine to reliably run a BBS or operate >as a SCADA master-station. Setting the pr_Window field in a process's process structure causes DOS to return an error immediately without asking for user assistance. -Matt
ford@crash.CTS.COM (Michael Ditto) (06/13/87)
In article <150@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: [ excerpts from wish list: ] >4) A new CON: device that uses a simple-refresh window, keeps track of 24 >lines by 80 columns of text, and has scroll bars to pan a full size screen >in the window. I have implemented part of this as an excersize, and it's >way faster and more memory efficient than smart-refresh ones. This is a good idea, and it would be trivial to throw in a feature of Sun's window system -- allow use of the vertical scroll bar to go back into previous pages of text that have scrolled off. >8) There should be an unettended mode, where all requestors automatically >return failure. This would allow the machine to reliably run a BBS or operate >as a SCADA master-station. This is not only already available, it is done on a per-process basis... the pr_WindowPtr (I think it's called) determines which window/screen (if any) the requester appears in. If it's zero, all errors are returned to the caller.
tenney@well.UUCP (Glenn S. Tenney) (06/13/87)
In article <8706120543.AA16187@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Setting the pr_Window field in a process's process structure causes >DOS to return an error immediately without asking for user assistance. Well, from painfull experience, not always! Since this is a true multitasking system, your process' pr_Window field only applies when the dos KNOWS that the request is yours. By the time that dos actually writes a track, it has no idea whose request(s) that write actually covers, hence an error at that time uses the pr_Window of the file handler's process. Ah, you might then think that you can alter the pr_Window of the handler. No way Jose, then the dos starts acting very weird. Then, we have the situation when our friend the validator needs to run (unbeknown to us). Again, it is it's own process, so our pr_Window has no affect. In other words, you really can't easily make a system be a padded cell and handle ALL errors yourself. What a shame... -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
mark@unisec.UUCP (06/14/87)
In article <8706120540.AA07721@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > > ...much text removed... > ----------- V1.2 Intuition additions ------------ > ReportMouse(Boolean,Window)(A0/D0) ;Change in the order of the args. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thanks, Bryce, I needed that! I gave up chasing a bug in the image editor of Egad! that I knew was being "revealed" by a call to ReportMouse. I just never dreamed that it was the CAUSE! A quick examination of my source reveals that ReportMouse calls do indeed have the args reversed (can't wait to go fix em'). Sigh - my fuzzy 37 year old brain was exposed to the Enhancer remarks about ReportMouse and I have the AutoDocs - the recall just isn't what it used to be. Thanks again, and take notice, those of you who are still trying to get Egad! to do what it's supposed to. Mark -- | Mark R. Rinfret, SofTech, Inc. mark@unisec.usi.com | | Guest of UniSecure Systems, Inc., Newport, RI | | UUCP: {gatech|mirror|cbosgd|uiucdcs|ihnp4}!rayssd!unisec!mark | | work: (401)-849-4174 home: (401)-846-7639 |
mcinerny@rochester.arpa (Michael McInerny) (06/14/87)
In article <1219@crash.CTS.COM> ford@crash.CTS.COM (Michael Ditto) writes: >In article <150@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: >>4) A new CON: device that uses a simple-refresh window, keeps track of 24 >>lines by 80 columns of text, and has scroll bars to pan a full size screen... >This is a good idea.... No! I _like_ the current console.device. It's simple, effective, and flexible. If I want a 700x400 character CON:, I can get it (I won't be able to read it :-). Please don't limit me to 80x24. I may _want_ a 40x10 line screen. If you want something fancier, get a different device (say, an ADM: or VT100: or ANSI: or TERM:), and use that. The console.device is nice just the way it is. -Michael McInerny "'console.device' user"
dillon@CORY.BERKELEY.EDU.UUCP (06/15/87)
One thing that *is* needed, however, is a proper implementation of multi-drop messages so Intuition doesn't compete with the console device for IDCMP messages. E.G. if you open an intuition window and catch NEWSIZE events, then attach a console device to the same window, the console device doesn't know when the window gets resized. -Matt
peter@sugar.UUCP (Peter DaSilva) (06/16/87)
Bryce Nesbitt writes: > > > 8) There should be an unettended mode, where all requestors automatically > > return failure. > > Already IS!!! Here's the code to turn it on: That does it for a process. Thanks... I missed that. I guess I should read the manuals more thouroughly. However, that code would have to be in all programs, right? So you couldn't call existing software (like, frex, ARC)? > > 5) Sizing and dragging windows shouldn't lock layers, instead they should > > use sprites to indicate the corners (a-la the HP Integral). > > !! YES !!. If this was done... Wow. Support. I'll have to be nastier: I was expecting flames :-> > > 6) Allow an image to underly the Workbench, ala the Xerox Star's "Mount Fuji". > > The workbench is just a backdrop window. I know that already. I would expect that just patching into the workbench window would be a bad idea, because disk icons would trash great holes in it when you moved them. Also, workbench windows are simple-refresh, so your mount fuji would decay pretty fast if you didn't modify workbench. Adding another backdrop window wouldn't help, 'cos then you woiuldn't be able to find your disk icons. > ( REMEMBER: If you use a 1.2 only function, open Intuition with library > verion 33, and die gracefully if not available) Or open with an older version, and check the intuition version before calling the function... you should definitely do this if you're writing a general purpose module that may not be opening Intuition itself.
peter@sugar.UUCP (Peter DaSilva) (06/17/87)
In article <347@sol.ARPA>, mcinerny@rochester.arpa (Michael McInerny) writes: > In article <1219@crash.CTS.COM> ford@crash.CTS.COM (Michael Ditto) writes: > >In article <150@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: > >>4) A new CON: device that uses a simple-refresh window, keeps track of 24 > >>lines by 80 columns of text, and has scroll bars to pan a full size screen... > >This is a good idea.... > > No! I _like_ the current console.device. It's simple, effective, and > flexible. If I want a 700x400 character CON:, I can get it (I won't > be able to read it :-). Please don't limit me to 80x24. I may _want_ > a 40x10 line screen. If you want something fancier, get a different > device (say, an ADM: or VT100: or ANSI: or TERM:), and use that. > > The console.device is nice just the way it is. 1) 80 by 24 was intended as an example. What's wrong with: CON:x0/y0/width/height/80/24/Title? 2) You're right. I even bitched about the same thing before. If you do design a new console device, don't make it console.device and don't call it CON:. I like TTY: myself (though VT100: has a nice ring to it). Boy, is my face red. 3) If there are too many programs that open console.device rather than CON:, or better yet a user specified name (NewCLI AUX: comes to mind), what can be done to allow CON: as well as TTY: windows (one reason I don't use CONMAN: it doesn't give me an alternative)?
michael@stb.UUCP (Michael) (06/21/87)
In article <8706120543.AA16187@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>8) There should be an unettended mode, where all requestors automatically >>return failure. This would allow the machine to reliably run a BBS or operate >>as a SCADA master-station. > > Setting the pr_Window field in a process's process structure causes >DOS to return an error immediately without asking for user assistance. > > -Matt False. The printer driver will still put up "Printer problems", the disk device will still put up "I/o error", the disk validator will still put up "Use disk doctor", etc. The point is, that only stops YOUR task's messages, not messages from tasks that you call. -- : Michael Gersten seismo!scgvaxd!stb!michael : Ground floor, comming up -- 1-3-7
andy@cbmvax.cbm.UUCP (Andy Finkel) (06/23/87)
In article <1601@stb.UUCP> michael@stb.UUCP (Michael) writes: >> Setting the pr_Window field in a process's process structure causes >>DOS to return an error immediately without asking for user assistance. >> >> -Matt > >False. The printer driver will still put up "Printer problems", >the disk device will still put up "I/o error", the disk validator will >still put up "Use disk doctor", etc. > >The point is, that only stops YOUR task's messages, not messages from tasks >that you call. Actually, the printer.device, since it runs as a task, rather than a process, strictly speaking has no pr_WindowPtr. So it uses the one from the calling task (ie, you). Printer requests are stopped by setting your pr_WindowPtr to -1. You're right about AmigaDOS, though. Any error message it can't figure out who it belongs to, it will put up a requester. There are two ways around this; both have their side effects. One could FindTask the file system process and change its pr_WindowPtr, (I haven't tried this, so really don't know just how horrible it might be. Maybe it will work perfectly) The other is to do a SetFunction on AutoRequest, and divert all requesters to the device of your choice (ie console, or the bit bucket). I was going to write the later and post it, but I'm pressed for time right now...sorry :-( >-- >: Michael Gersten seismo!scgvaxd!stb!michael >: Ground floor, comming up -- 1-3-7 andy finkel -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "The goal of Computer Science is to build something that will last at least until we've finished building it." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
eberger@godot.psc.edu (Ed Berger) (08/19/88)
OK folks, here is my ideas for improving the AMIGA. First, I think there could be a much larger market for the machines if they were geared towards, the "Scientific" user. 1) How about a greek key with all the greek letters printed on the keyboard ala C= graphics on the 64. A good interface program to TEX could be made, or other scientific text processing, without having to learn all kinds of control sequences/grabbing the mouse everyother letter. 2) Subscript, and Superscript keys, also to be used just like shift keys. 3) I want this as a new 'standard' keyboard, so that most software will track. 4) I like the PhoneNET system better than appletalk, modular plugs instead of weird Appletalk Connectors. Suggestion: Go Modular! 5) Include a free Video D connector with every AMI, I'm tired of seeing hacked 25pin units. 6) Either a standard network or multiple serial ports. I want to be able to control a signal generator, capture data, and use a modem in multitask mode. SCSI is another possibility 7) More UNIX compatability, specifics UNICOS system compatibility. Be able to transport to and from CRAY. OK so Ami takes a zillion times longer Maybe Commodore should become an industrial affiliate of PSC. Looking forward to your comments: Ed Berger eberger@cpwpsca.bitnet
leein@uicsrd.csrd.uiuc.edu (08/21/88)
On Aug 19, 1988, Ed Berger at eberger@godot.psc.edu wrote: /* ---------- "Amiga Wishlist" ---------- */ >OK folks, here is my ideas for improving the AMIGA. > >First, I think there could be a much larger market for the machines >if they were geared towards, the "Scientific" user. >1) How about a greek key with all the greek letters printed on the > keyboard ala C= graphics on the 64. A good interface program to TEX > could be made, or other scientific text processing, without having to > learn all kinds of control sequences/grabbing the mouse everyother letter. >2) Subscript, and Superscript keys, also to be used just like shift keys. >3) I want this as a new 'standard' keyboard, so that most software will track. > > ..... > >Looking forward to your comments: >Ed Berger You missed the single-most important shortcoming of Amiga. That's the damm screen flickering problem in its high resolution mode! 200 x 700 is simply not enough for today's PC. Commodore invented some kind of a blit chip which gave us 4096 colors while others give only 256 colors at most. However, Commodore has been trapped by that self-made pitfall, and they could not improve that blit chip because of, seemingly, the backward software compatibility problem---I am not so sure about the exact reason. If that is not the case, they are not so serious about Amiga. You mentioned the Greek key. Maybe I am the predecessor who insisted on its necessity. I even wrote a letter to IEEE P1003 POSIX Committee so that they could include the Greek key as an extended ASCII set using most of 128 combinations of unused 8-bit combinations. But their reply was negative. They are mostly computer scientists, not just scientists nor engineers. They see the Greek characters not as the scientist and engineers' mothertongue, but as one of foreign alphabets. And their vision is somewhat futuristic. They consider Postcript language as the new ASCII. They are illusionist. They do not realize how many percentage of computer users depend on character- based terminals. I was simply frustrated after the futile effort. Hugh SONG, U. of Ill Direct your mail to: song@uispg.csl.uiuc.edu
dnelson@umbio.MIAMI.EDU (Dru Nelson) (08/22/88)
in article <42600042@uicsrd.csrd.uiuc.edu>, leein@uicsrd.csrd.uiuc.edu says: > On Aug 19, 1988, Ed Berger at eberger@godot.psc.edu wrote: > /* ---------- "Amiga Wishlist" ---------- */ >>OK folks, here is my ideas for improving the AMIGA. >> >>1) How about a greek key with all the greek letters printed on the >> keyboard ala C= graphics on the 64. A good interface program to TEX [...stuff deleted ] >>Looking forward to your comments: >>Ed Berger > > You missed the single-most important shortcoming of Amiga. That's the damm > screen flickering problem in its high resolution mode! 200 x 700 is > simply not enough for today's PC. We are all aware of this. The interlaced mode was implemented when 400 vertical was VERY expensive to the Non Scientific market. They tried to give the users something; they didn't decide on what we should have. They gave it to us to decide. I do hope, though, that Commodore/Amiga will fix this problem. > > Commodore invented some kind of a blit chip which > gave us 4096 colors while others give only 256 colors at most. However, > Commodore has been trapped by that self-made pitfall, and they could not > improve that blit chip because of, seemingly, the backward software > compatibility problem---I am not so sure about the exact reason. If that is > not the case, they are not so serious about Amiga. > True, but I don't think that it's not backwardly compatible since most programs go through the Rom routines. I think the problem is with the DMA bandwith that people mention (I don't understand the DMA problem, though. I missed the article explaining that) > You mentioned the Greek key. Maybe I am the predecessor who insisted on > its necessity. I even wrote a letter to IEEE P1003 POSIX Committee so that [ .. stuff deleted ] > as one of foreign alphabets. And their vision is somewhat futuristic. They > consider Postcript language as the new ASCII. They are illusionist. > They do not realize how many percentage of computer users depend on character- > based terminals. I was simply frustrated after the futile effort. > > Hugh SONG, U. of Ill > Direct your mail to: song@uispg.csl.uiuc.edu Why can't the scientific programs do the greek key feature themselves. All they would have to do is let the user change a mode (supported by the program) to consider input as greek or whatever language. There wouldn't be incompatiblities because they would just use the standard alphabet to stand for the greek. The 'a' key would stand for the alpha symbol. The shift 'a' or 'A' would be the uppercase alpha. No incompatiblities. This would be easier to implement than having to dedicate a key to the function (for the time being). Speaking of character based terminals, doesn't the ANSI character set have greek symbols? I've seen them on I*M's. -- Dru Nelson UUCP: (gould || uunet)!umbio!dnelson Miami, Florida MCI: dnelson Internet: dnelson%umbio@umigw.miami.edu
jms@antares.UUCP (joe smith) (08/23/88)
In reference to Greek letters on the keycaps: What *SCII codes are assigned to the Greek letters? They are not in the US-ASCII 7-bit set, nor in the IA5 (International Alphabet) 8-bit set that the Amiga uses. And the current discussion in comp.fonts is about the Russian character set. So, how many font building programs already know about Greek, Russian, and other non-Latin alphabets? -- +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
murphy@pur-phy (William J. Murphy) (08/24/88)
Speaking of non-Latin characters, I just want to get a Chinese character font. Maybe a 14bit ASCII code would do. Seriously, there are word processors for Chinese now. One can type in a Romanized pronunciation and be presented with a choice of characters to display. It seems rather slow, but it beats handsetting the type Having been a MAC enthusiast, the MacWrite uses the alternate keycap to display a limited set of greek characters within a standard font like Geneva or Chicago. Using the C= seems like a good choice. BTW, are there any scientific publication quality graph rendering programs for the AMIGA? I have been using the program called GRAPHER put out by Golden Software for the PC. I would really like to do likewise with the AMIGA. I have heard of Doug's Math Aquarium, and some other programs, but they seem to designed for plotting out functions and playing with visualizing Mathematics. I need to take data and create a publication quality plot. E-mail me any info about the graphing. TIA William J. Murphy murphy@newton.physics.purdue.edu
swordfis@pnet51.cts.com (Tim Mitchell) (08/26/88)
Am I way off base, or would it be fairly simple for someone to write a bunch
of foreign keymaps (like Greek - Chinese would be fairly complex) and make a
lot of money?
UUCP: {rosevax, crash}!orbit!pnet51!swordfis
INET: swordfis@pnet51.cts.compage@swan.ulowell.edu (Bob Page) (08/30/88)
swordfis@pnet51.cts.com (Tim Mitchell) wrote:
>write ... foreign keymaps (like Greek - Chinese) ... make a lot of money?
You mean fonts? Yeah, probably. If you mean keymaps, probably not,
as Chinese 'typewriters' don't look anything like those in the West,
so there is no rational mapping.
..Bob
--
Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
"What a wonder is USENET; such wholesale production of conjecture from
such a trifling investment in fact." -- Carl S. Gutekunstmp1u+@andrew.cmu.edu (Michael Portuesi) (09/28/88)
> *Excerpts from ext.nn.comp.sys.amiga: 21-Aug-88 Re: Amiga Wishlist* > *leein@uicsrd.csrd.uiuc.e (2242)* > Commodore invented some kind of a blit chip which > gave us 4096 colors while others give only 256 colors at most. However, > Commodore has been trapped by that self-made pitfall, and they could not > improve that blit chip because of, seemingly, the backward software > compatibility problem---I am not so sure about the exact reason. If that is > not the case, they are not so serious about Amiga. 1) The chip which performs blitting operations is a physically different chip than the one which gives you 4096 colors. 2) Improving the Amiga chipset will not introduce backward software compatiblity problems. Please make sure you know the exact reason before you go around spreading untruths that someone else might believe. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "my friends say she's a dumb blonde, but they don't know she dyes her hair"