stevem@ibmpcug.co.uk (Steve Marsden) (09/01/90)
Greetings!
I am currently investigating the use of PostScript as a standard
vehicle for a business graphics application running under AIX 3.1
on the RS/6000 series. Specifically, I'm looking at using the
AIXwindows Display PostScript (DPS) for the graphics display and
manipulation within a Motif application framework. The intention
would be to also use PostScript as the hard-copy intermediate
language, and to export Encapsulated PostScript for use by other
applications.
So far, I have done some prototyping of a simple application,
using the Motif toolkit to build menus etc, and having a main
DrawingArea widget, into whose window the DPS is drawn. Most of
the stuff I want to do is okay, but I have now got some questions
that I hope someone out there will be able to help me with.
1) Dynamic drawing
In the past, when I have wanted to do a dynamic dragging operation,
I have used XOR mode graphics to draw the object being dragged
over the background, and then undraw it again, leaving the
background as it was. As far as I can tell, this is not possible
using DPS, as it adheres to the opaque painting model.
How do I do this kind of operation using DPS?
If I can't do it using DPS, do I resort to Xlib for this case,
drawing into the same window with an XOR GContext?
2) Expose/Redraw
What I would really like is for the picture in my window to be
redrawn when the window gets exposed, without requiring the
intervention of my application.
Is there any way I can do this?
3) Input Correlation
When the user wishes to select an object from the window display,
my application has to determine which object it is that coincides
with the point selected. It seems from the documentation that the
inufill/inustroke etc operators should be used to do this - is this
the case?
4) PostScript language output
I am currently using the DPS client library to do my DPS output.
Is there a way to get hold of the PostScript language text that
is equivalent to the series of client library function calls that
I'm doing? To explain further, take a simple piece of code that
does this:
DPSmoveto(ctxt, 100.0, 200.0);
DPSlineto(ctxt, 500.0, 500.0);
DPSstroke(ctxt);
is there any way to re-execute this code and capture a set of
PostScript operators in string form, such as:
100.0 200.0 moveto 500.0 500.0 lineto stroke
which I could then send to a PostScript printer?
Thanks in advance for your help.
Steve Marsden - really working for Logica UK Ltd, London, England.
--
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- bb@beach.cis.ufl.edu (Brian Bartholomew) (09/01/90)
Unless you have some ironclad reason for sticking with the X Window System (such as, it's written into your contract), I advise jetisonning it immediately in favor of NextStep. You have already gone a third of the way by choosing Display Postscript. Based on what I have seen at my site (tripping incredible X programmers who submit code to an MIT window manager writer, who then proceeds to use it, versus our area NeXT rep reproducing a complex interface in 9 minutes), you will be doing your business a criminal-sized disservice by handicapping them with X. NextStep is so much nicer (read: better designed, factor of 100 more productive to program), that you will produce interfaces in a week that would take you several months (I'm amortizing training times in here also) to reproduce in X. But, don't just take my word for it. Draw out a few sample pictures of an interface that you would like to impliment, take a few key programmers along, and let a NeXT sales rep (yes, a salesman, not a programmer) demonstrate building your interface in 15 minutes. Then, take the same drawings to an X programming expert (have fun finding one), and challenge him to reproduce the performance of the NeXT salesman. Challenge: I bet that you cannot give me reasons to use X (by private email, please), that I cannot demonstrate to be flawed or outright incorrect. You have already stated that you are going to use an RS/6000 for a server; a NeXT I or NeXT II makes a dandy workstation. While you are at it, total up the purchase costs of X analogues of all the NeXT software that you see that you think would be valuable to your customers, and add that in with the purchase costs of your X machines. Lastly, if you really, really, really want to run a bit of X, it is already out for the NeXTen. You can run X and NextStep at the same time, if you are required to have the X connectivity. Make sure you have 16 Megs in the machines that do this, however. "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@beach.cis.ufl.edu -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@beach.cis.ufl.edu
kent@decwrl.dec.com (Christopher A. Kent) (09/02/90)
If you're doing any sort of color work, you probably don't want to use XOR for what you're doing. The most straightforward thing to do is do all your painting into a pixmap, not into the DrawingArea widget. The use XCOpyArea to copy the pixmap (probably just the affected area) to the window. You can keep as many generations of pixmap as you want (or as the server lets you). Having a backing pixmap also makes exposure handling very easy. (Using backing store is an alternative, but I don't know if the IBM server provides it.) To get a text copy of the output to your context, create a text context. That's what they're for. Depending on how your program is set up, either just re-traverse your database, generating DPS calls into the text context, or chain a text context to your drawing context and capture the PS as you go. chris Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
kent@wsl.dec.com (Christopher A. Kent) (09/06/90)
There's one compelling reason to develop for X instead of NeXTStep: you want to reach an installed base, rather than counting on a religious conversion on the part of your entire intended market. Besides that, though, much of what you say is true. (Except that I'm not really sure that trying to use the DPS extension is 1/3 of the way to choosing to use NeXTStep -- far less, I'd guess.) -- Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
dls@dlsrt.austin.ibm.com (David Skeen;3E-75) (09/06/90)
I would guess that use of C++ with the InterViews class library out of Stanford would dramatically close the gap between X and NextStep. Dave Skeen
murphyn@motcid.UUCP (Neal P. Murphy) (09/07/90)
bb@beach.cis.ufl.edu (Brian Bartholomew) writes: >by handicapping them with X. NextStep is so much nicer (read: better >designed, factor of 100 more productive to program), that you will >produce interfaces in a week that would take you several months (I'm >amortizing training times in here also) to reproduce in X. But, don't >Challenge: I bet that you cannot give me reasons to use X (by private >email, please), that I cannot demonstrate to be flawed or outright >incorrect. You have already stated that you are going to use an I agree with you completely: NeXTStep is an order of magnitude faster than (at least) UIMX. But you should compare apples to apples; NeXTStep is an interface management system/interface design tool, whereas X is a collection of functions that facilitate a windowed system, much like Apple's Macintosh ToolKit, Suns's Sunview and NeWS, and MS Windows. If you are designing applications to run on a single system, NeXTStep is the way to go. However, if you are designing applications to run on a network (where the application runs on one of a number of remote machines, while the graphical display is handled on one of any number of display machines), then X is the kit to use. NPN