dan@china.uu.net (Dan Williams) (10/12/89)
I will soon be taking a NeWS application built a year ago and trying to port it into X11/NeWS. We don't have the X11/NeWS product in house yet and I was wondering about experiences that others have had with this. How much has NeWS changed and what is the quickest way to get our application up? -- | Dan Williams (uunet!china!dan) | FRP: It's not just a game, | | MCDONNELL DOUGLAS | it's an adventure! | | Denver CO | "Of course thats just my opinion" |
doc@jalapeno.UUCP (Tom Dockery) (10/18/89)
Dan Williams writes: > > > I will soon be taking a NeWS application built a year ago and >trying to port it into X11/NeWS. We don't have the X11/NeWS product in >house yet and I was wondering about experiences that others have had with >this. How much has NeWS changed and what is the quickest way to get our >application up? > > We have done that very thing, and found not *too* many problems. Because X/NeWS still includes the lite package, as well as the new tNt package, existing NeWS apps may run with no problem. Then again, because there are some differences in the PostScript implementation (especially dealing with paths), and some magic dictionaries have changed, and the fonts are different, and so on, the older stuff may break, render oddly, or behave somewhat weirdly. We have done that very thing, and found not *too* many problems. Because X/NeWS still includes the lite package, as well as the new tNt package, existing NeWS apps may run with no problem. Then again, because there are some differences in the PostScript implementation (especially dealing with paths), and some magic dictionaries have changed, and the fonts are different, and so on, the older stuff may break, render oddly, or behave somewhat weirdly. Our stuff, ClientFocus(tm), now runs reasonably well in both environments, with only an occasional check on which server we're using. Most of our porting problems had to to with path handling when rendering. XNeWS is actually closer to Adobe's implementation of PS, so fixing those problems also cured some bugs we had in printing. The applications that seem to break easiest are things that rely on intrinsic dictionary structures and hacks; Class browsers, color editors, terminal emulators, and such. If you use the lite package, your stuff won't conform to OpenLook specs (if that concerns you). We haven't really used tNt, but it should open an OpenLook look (sorry, I couldn't resist :={) ). The summary of all this is, the quickest way to get your application up is to simply try it under XNeWS; it may work immediately with no, or only cosmetic, problems. If you want OpenLook compliance and the multi- inheritance model that tNt gives you, though, you have quite a bit more work ahead of you. One additional note: XNeWS has gone a *long* way toward curing the server growth problems of NeWS. It even includes tools that aid in the location of problem areas in your NeWS code memory management. And the new "cleanoutdict" function is a big aid there, too. Good Luck. Tom Dockery Market Focus Technologies, Inc.
rxb@ASC.SLB.COM (Rafael Bracho) (10/19/89)
I just finished porting a fairly complex NeWS application (close to 75K lines of PostScript) to the merged server, taking me about two weeks of work. These are a few of the issues I found: 1. Input has changed somewhat; in particular, the function keys no longer work with the litewindow toolkit -- we implement a window system that is a descendant of litewindows. 2. The focus (re: the Extended Input System chapter of NeWS 1.1) is no longer and array of canvas and process but rather just a canvas. Some of our code broke because of that. 3. The merged server has the concept of "packed arrays". The command setpacking may be used so the server packs all executable arrays. Unfortunately, the buildimage operator doesn't work with packed arrays. 4. X11/NeWS follows the red book a lot more closely so there were a number of bugs we uncover in our code. For example, erasepage now blanks out the whole canvas, irrespectively of any clipping path that may be in effect. 5. A host of bugs were related to the fact that canvases are, internally, kept in the X11 coordinate system (upper-left corner is the origin) and not in the PostScript one (the origin being the lower-left one). Normally this shouldn't affect anyone since the defaultmatrix is set properly everytime the canvas is reshaped -- previously it was always the identity matrix. In NeWS 1.0, however, the default matrix contained very small translation factors that would become significant with large scaling. We got in the habit of doing "matrix setmatrix" instead of "initmatrix" and in NeWS 1.1, these two were identical. This is obviously no longer the case. 6. Imagecanvas is much more consistent to the PostScript image operator. Under NeWS 1.1, to "imagecanvas" a regular canvas -- i.e., obtained via newcanvas -- the receiving canvas had to be scaled by the size of the source canvas; even though the source canvas' coordinate system was not the unit square. Doing this in X11/NeWS results in double scaling so you'll probably won't get anything on the screen -- the server refuses to "imagecanvas" anything that results in more than 32767 pixels in either dimension. Either make the source canvas be mapped to the unit square, or the receiving canvas have pixel units. 7. Readcanvas returns a canvas with its default coordinate system being the unit square (more consistent with buildimage, and better for imagecanvas, see above). Thus to "imagecanvas" it, one must scale the receiving canvas by the size of the rasterfile read -- this was also true in NeWS 1.1. Previously, however, one could "setcanvas" to the result of readcanvas knowing that the default matrix was in pixels (like a canvas obtained via newcanvas). In general the X11/NeWS server is much nicer than NeWS 1.1. There are a few rough edges, particularly with the CG6 (GX or LEGO) board, and I don't think performance is quite up to par with NeWS 1.1. In our case, we had some bound-checking code in our inner loops to avoid crashing the 1.1 server that is no longer needed so we don't really see *drawing* performance degradation. Interactions, particularly dragging, seem a bit slower, though. Rafael Bracho Schlumberger Austin Systems Center rxb@asc.slb.com