kim@amdahl.uts.amdahl.com (Kim DeVaughn) (03/21/88)
In article <4599@garfield.UUCP>, john13@garfield.UUCP (John Russell) writes: > BAD - it is $%#@$% irritating to have a large part of the screen obscured > every time I want to do some sort of file operation; especially doing > something like turning off capture, and having to click a close-gadget of > a window that tells me capture has ended. [ Cross-posted to .tech for a reason. See below. ] This will happen if you've *closed* the Status/Xfer window, but NOT if you just push it to the back after having responded to the requester when you initiated the Capture function. This is true for all infomational messages written to the Status/Xfer window. As long as it's open (but in back of the main window), it should stay there until you do something that causes a requester to pop up for input. One exception: when you specify an initial script on the command line when first invoking vt100 (e.g., "run vt100 callwork") the Status/Xfer window gets opened and is WindowToFront()'d. I'd like to see it left in the back myself. If this is not the case for you, please email details of your setup (screen type, etc.) Your vt100.init script could prove useful. > I move the window around, resize > it, move it to the back, but it always seems like it gets in the way the > next time I change directories, or has to be made bigger to monitor a kermit. His name is "Murphy". :-) > Again on the bad side, you can make it 'hang' by performing a normal action - > clicking a close box - if you do it at the wrong time (for me this was 10 > seconds after the first time I booted it). Tony's looking at this, I think. > I'd like to see the interface modified a bit. There should be some way to > say "make the window go away as soon as possible" so it would maybe display > messages for a few seconds then scat. Good suggestion. Maybe a toggle in the Utilities menu that would optionally cause a WindowToBack() on the Status/Xfer window? Having it happen immediately after the requester is responded to shouldn't require much code. For *now*, try using one of the PD programs that brings a window to the front with a couple of mouse clicks (ClickToFront, ClickUpFront, others). Chances are, your mouse pointer won't be in the Status/Xfer window area, so you won't even have to move her ... just reach over, and click-click. > Perhaps a "set window position and size" > option in the config file. I've talked with Tony before about specifing the size and position of the Status/Xfer window in the vt100.init file. It'd be a fair amount of code to do all the parsing and error checking of the input parms, and of limited value because, as you mention, you'll probably move it around and resize it anyway. I'd rather see the code used to support additional protocols, etc. Wouldn't you? And you *do* have the sources, so you can always tailor the window's initial position ... > And it shouldn't have a close box at times when > the close box is dangerous -- maybe during file transfers it could be made > borderless so as not to get in the way? Maybe just get rid of the close altogether, and rely on front/back gadgets to get it out of the way? I would also like to see the close gadget removed from the main vt100 screen, and it be made into a menu item. Only. More times than I'd like to admit I've been doing something on another screen, flipped over to vt100, and hit the L-Mouse-Button (well, really I use L-Alt-Amiga) to select it's screen. Naturally, the mouse pointer was right on top of the close gadget area. You know the rest. This has usually happened within 10% of finishing a looooong file xfer. Murphy, remember. > PS There are problems with the "done" gadget in the requester as well at > certain times. Being looked into. Now, here's one I'd like some info on (and why I've cross-posted this to .tech): Ever notice while resizing a window or moving it around that an in-progress file xfer *stops* until you release the L-Mouse-Button? Well, it does [see, led's on modems *are* good for something]. This is not restricted to vt100's window(s) either, but applies to any window in the system. This can cause havoc if you're trying to talk to a system that doesn't relax their timeout specs between packets. I forget why Tony said this happens (something to do with Layers, if my memory serves me right), but does anyone know of a solution. Seems a shame if there isn't one, as this *is* a multitasking machine, and moving windows about has NOTHING to do with the serial port, per se. Anyone? Finally, I should mention that Tony is still accepting suggestions for what goes into v2.9 or v2.10 (or will that one be v3.0 ?). His email address is the same as mine ... just substitute "acs" in place of "kim", or you can send them to me. A couple of things I've asked for is support for multiple active "on" and "wait" script commands, and for the ability to set/change the function key definitions "on the fly", rather than just from a script. Tony's looking at these, but they may not make v2.9. Keep those cards and letters coming in ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
dpvc@ur-tut (Davide P. Cervone) (03/25/88)
In article <25089@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: >Ever notice while resizing a window or moving it around that an in-progress >file xfer *stops* until you release the L-Mouse-Button? Well, it does [see, >led's on modems *are* good for something]. > >This is not restricted to vt100's window(s) either, but applies to any window >in the system. This can cause havoc if you're trying to talk to a system that >doesn't relax their timeout specs between packets. This has to do with layers. When you size or move a window, Intuition locks the screen's layers so that rendering does not occur to the window or screen while you are moving the window around. In general, this is a good thing, but it also means that any I/O to a window on that screen will block until you let go of the window. I assume that VT100 is updating a status window (telling you how many packets are transfered). This update is being blocked, so VT100 does not go on to receiving the next packet until the output occurs. That's the holdup. There's very little that can be done about it, unfortunately. Holding down the MENU button also locks the layers. >/kim >UUCP: kim@amdahl.amdahl.com Davide P. Cervone dpvc@tut.cc.rochester.EDU