Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!daver!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.tech Subject: Re: asd Message-ID: <1990Dec24.090341.2297@zorch.SF-Bay.ORG> Date: 24 Dec 90 09:03:41 GMT References: <925@boing.UUCP> <7335@sugar.hackercorp.com> <6301@amiga.UUCP> Organization: SF-Bay Public-Access Unix Lines: 51 In article <6301@amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: [...] >I believe that it is possible to port the simple "workbench class" >applications someday, but that will indeed be quite a while (layers >and Intuition have to be ported, first). >But I don't think that this "emulation" will necessarily be the best way >to write device-independent applications. >For one thing, suppose the "retargeting" supports graphics of varying >resolution. The "retargeted graphics library" knows how to scale things >(poof, through magic). How do applications support clicking on graphics >objects? The input model has to be emulated, and tranformed, as well. I know this isn't answering the question you asked, but it is a little goodie that might prove of use. In a SIGGRAPH tutorial he taught some years ago, Alvy Ray Smith described the original paintpot graphics program, which he had developed (at New York Institute of Technology, I think). Back in the days before swappable screens or very fast graphics, they'd solved the problem of having a full screen drawing surface by running a two headed system with the command menus on one, monochrome screen, while the picture was on the other, color screen. (Actually, this is enough like the system being proposed here to deserve a lot closer look, if anyone has the source material.) Anyway, the problem of swapping the cursor's "attention" from the control screen to the drawing screen needed solving. They chose a double width digitizing tablet (pre "mouse" days; they had "pucks"), and used a gestural language; if you went "significantly" left off the edge of the control screen with the cursor, your cursor showed up on the graphics screen. If you went significantly right off the edge of the graphics screen, your cursor showed up on the control screen. Behind the scenes, of course, a new input "inverse" transform was shifted into place going to the control screen or the graphics screen, since there is no given that the two screens had the same resolution, but the mouse motions should feel the same on each. Also, the "pick" list for the control screen menu items had to be disabled for the same locations on the graphics screen. For the Amiga, the mouse works well as a replacement for the double wide digitizing tablet, and, in the case where the 24 bit screen contains object, rather than pixel, -oriented entities, a new "pick" list (and possibly a whole new routine: menus and dimension arrows don't "pick" the same way) could be swapped in while on the high res screen, to solve the "clicking on an item" problem. It's an approach that worked in the past. Kent, the man from xanth.