peter@sugar.UUCP (Peter da Silva) (11/23/87)
This goes into the category of "fluff". Could you make the initial CLI window open up to NormalDisplayRows by NormalDisplayColumns? This goes into the category of "would be real useful, and shouldn't be too hard if I'm not totally off base". Allow a window to be dragged off the screen, as the Mac and ST do. It should not be hard (isomorphic to dragging the window behind anither window), and should be possible to use the solution to solve the Space Time Distortion bug. I've mentioned this one already, but didn't get any response. I presume it got lost, so I'm trying again. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
hsgj@batcomputer.tn.cornell.edu (Dan Green) (11/25/87)
In article <1106@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Could you make the initial CLI window open up to NormalDisplayRows by >NormalDisplayColumns? >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter Two points, both related to the CLI: 1) What Peter suggested would be a good idea, but I just checked and found out that NormalDisplayRows is NOT updated if you are in interlace. This is neither good nor bad; however, if you wanted your initial CLI to open up to the full screen size, it should be like: width = ndcolumns; height = (lace == TRUE) ? ndrows * 2 : ndrows; This would fix both morerows and having your wbench be interlaced via preferences. 2) An annoying 'gotcha' in CON:. Try this if you enjoy really nasty non-gurus (eg it frogs up the amiga but you don't even get a RED box): 1> COPY * CON:0/0/0/0/DeathTongue Plainly it crashes because the window is of nil size. Whose fault is this? Obviously the users, because of the ridiculous settings. But really, for CON: to do a check on the validity of its window arguments would be trivial. This 'gotcha' caused me to lose about 14 hours worth of work. You really do not want to hear the full, gruesome story... [But if someone insists :-) Misery loves company] So, just two minor suggestions for CON: (or CLI, whatever). Thanks for the patience to read this thing... By the way, I hope the folks at CBM don't think I'm 'flaming' the system by suggesting stuff. I just figure, if you're rewriting some stuff already, rewriting a few other lines here and there won't be too much of a pain. -- Dan Green -- ARPA: hsgj@tcgould.tn.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
carlson@ernie.Berkeley.EDU (Richard L. Carlson) (11/25/87)
Here's yet another suggestion for eliminating a minor inconvenience: Currently, when a system requester is created, the workbench screen is implicitly brought to the front so that the requester is guaranteed to appear. However, when the requester is satisfied, workbench is *left* as the frontmost screen; and Amiga-M must be used to return to the previously-frontmost screen. I would certainly not classify this as a major problem, but I think that restoring the frontmost screen when a requester disappears would improve the user interface of the Amiga (and I can imagine an inexperienced user calling up, say, an interlaced VT100, getting a system request to re-insert the workbench disk [to load in the serial.device], re-inserting workbench, and then wondering where his VT100 screen went). Is there a major problem with restoring a screen that I have overlooked? Or is this just something that doesn't bother people (except me :-)? -- Richard Carlson carlson@ernie.Berkeley.EDU ...!ucbarpa!ernie!carlson
bryce@hoser.berkeley.edu (Bryce Nesbitt) (11/25/87)
In article <21943@ucbvax.BERKELEY.EDU> carlson@ernie.Berkeley.EDU.UUCP (Richard L. Carlson) writes: > >Here's yet another suggestion for eliminating a minor inconvenience: > >Currently, when a system requester is created, the workbench screen is >implicitly brought to the front so that the requester is guaranteed to >appear... >...Is there a major problem with restoring a screen that I have overlooked? There is already a facilty in the OS to address your complaint, and fix your example of the VT100 screen. All it requires is some dillegence on the part of the programmer: By default the DOS will place requesters relating to your process in the Workbench screen. If your program opens a custom screen it must direct DOS to the new location. This code fragment show how to do that: ------- cut here ------ #include "libraries/dosextens.h" ... struct Process *mproc; struct Window *window; APTR temp; ... mproc=(struct Process *)FindTask(0L); temp=mproc->pr_WindowPtr; /* save old value */ mproc->pr_WindowPtr=(APTR)window; /* set a pointer to any open * window on your screen */ ... mproc->pr_WindowPtr=temp; /* restore value _before_ CloseWindow */ ... CloseWindow(window); |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U WARNING: hoser's spool directory eats a *lot* of mail. :-(
acs@amdahl.amdahl.com (Tony Sumrall) (11/25/87)
Distribution: In article <21945@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu.UUCP (Bryce Nesbitt) writes: >By default the DOS will place requesters relating to your process >in the Workbench screen. If your program opens a custom screen it must >direct DOS to the new location. Should VT100R2.8 include this by default? - should a toggle variable be created to allow the user to choose? E-mail me and I'll do what the masses instruct! -- Tony Sumrall acs@amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]