dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/31/87)
>A note to morerows users. We are using a much more elegant way to control >wb size then the morerows hack, so we do not plan on supporting the >morerows magic. No problem... morerows is the type of program you run once then forget about. If the new release will have overscan support in preferences, then there is no longer any need for the morerows hack, and application programs won't know the difference. Speaking of which, there is also a philisophical angle to all of this. There are many people out there who's monitors cannot support an overscan screen. I think it would be incredibly stupid for developers of software to 'force' an overscan screen on such people. So what you do is (A) write your program such that it can handle any screen size... an extremely easy thing to do, and (B) never open a screen physically larger than the workbench. Thus anybody who uses an overscan workbench (morerows) would automatically inform applications that it is O.K. to use overscan themselves. This whole MaxXMouse/MaxYMouse problem is due to openning screens which are larger than the workbench. My answer to all your complaints are, simply, USE MOREROWS AND DON'T WRITE APPLICATIONS WHICH OPEN SCREENS PHYSICALLY LARGER THAN THE WORKBENCH'S. As far as I'm concerned, the bug doesn't exist. -Matt
bobb@tekfdi.TEK.COM (Robert Bales) (11/03/87)
In article <8710312052.AA12848@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > So what you do is (A) write your program such that it can handle any >screen size... an extremely easy thing to do, and (B) never open a screen >physically larger than the workbench. Thus anybody who uses an overscan >workbench (morerows) would automatically inform applications that it is O.K. >to use overscan themselves. I think "never" is too strong a word. Consider any type of video application. For the "control" part of the program, I'll want to see everything on screen --> normal scan. But for the "display" part, I want overscan to eliminate borders on the videotaped image. This may not be important in the context of this discussion, as I am unlikely to use the mouse during thr display portion of the program. Bob Bales Tektronix, Inc. I help Tektronix make their instruments. They don't help me make my opinions.
keithd@cadovax.UUCP (Keith Doyle) (11/07/87)
In article <8710312052.AA12848@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > This whole MaxXMouse/MaxYMouse problem is due to openning screens >which are larger than the workbench. My answer to all your complaints are, >simply, USE MOREROWS AND DON'T WRITE APPLICATIONS WHICH OPEN SCREENS >PHYSICALLY LARGER THAN THE WORKBENCH'S. As far as I'm concerned, the bug >doesn't exist. DPaint and IFF ANIM files exist that may be larger than the current workbench. Any program that displays these, and provides mouse interaction (as mine does) gets caught by the "bug". Distribution of PD demos that you can just "put the disk in df1: and click on the icon" becomes impossible without some kind of workaround. Imagine a slideshow program that doesn't know how big the screens are going to be, can be run in df1: from anybodies CLI or WorkBench boot disk, and provides mouse interaction while the images are being displayed. Imagine the slideshow supports IFF overscan and IFF ANIM. Morerows does not address the problem. BTW, you won't have to just imagine for long. Expect a "now shipping" product announcement around Thanksgiving. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170