amir@pilat.Israel.Silvaco.COM (Amir J. Katz) (02/27/91)
Hi Everybody,
This is regarding PEX, (PHIGS Extension to X):
1. What is the status of it?
2. Is it available publicly or commercially?
3. Has anyone tried to use it?
I am new to UseNet and I don't have access to previous articles, so this
has probably been asked before.
--
-- Thanks,
Amir J. Katz, System Manager
E-mail: amir@taux01.nsc.com
Phone: +972 52-570713
Fax: +972 52-570719
Snail-mail: Amir J. Katz, Silvaco Israel Ltd.
19 Maskit St., Herzelia, Israelpmartz@undies.dsd.es.com (Paul Martz) (03/01/91)
In article <AMIR.91Feb27125955@pilat.Israel.Silvaco.COM>, amir@pilat.Israel.Silvaco.COM (Amir J. Katz) writes: > Hi Everybody, > > This is regarding PEX, (PHIGS Extension to X): > 1. What is the status of it? The current PEX protocol is 5.0P, and there will eventually be a 6.0. Sun Microsystems' contract with MIT to develop a PEX Sample Implementation has recently ended. The PEX-SI is based on the 5.0P protocol, and should be shipped with the X11R5 tapes. > 2. Is it available publicly or commercially? University of Illinois has produced their own PEX implementation, based on a less-recent version of the protocol. It is ftp-able from somewhere, I don't have the details. The official PEX-SI mentioned above will be publicly available just like X. Many comercial companies have PEX-savvy X servers, and supply PEX-based PHIGS libraries; Digital Equipment and Evans & Sutherland are two of them, and there are probably others. > 3. Has anyone tried to use it? Oh yes. PEX is a reality. E&S has developed or ported several applications to our PHIGS/PEX implementation. (I worked in the applications porting group for the past year and did alot of this work myself.) > -- Thanks, > > Amir J. Katz, System Manager > > E-mail: amir@taux01.nsc.com > Phone: +972 52-570713 > Fax: +972 52-570719 > Snail-mail: Amir J. Katz, Silvaco Israel Ltd. > 19 Maskit St., Herzelia, Israel -- -paul pmartz@dsd.es.com
gregc@cgl.ucsf.edu (Greg Couch) (03/01/91)
Does the PEX standard specify how the PHIGS API and X work together? Specifically, if you want to use X events for input, could you still use PHIGS for picking? The current DEC PHIGS product provides such a method, a pphittest function to do picking in an PHIGS output-only workstation. And I've heard that in IBM's graPHIGS, you can pass an X event to the graPHIGS widget for picking. Please tell me that this will be standardized soon. - Greg Couch gregc@cgl.ucsf.edu
raf@fib.upc.es (Rafal Korycinski) (03/01/91)
In message <gregc.667779263@zeno.mmwb.ucsf.edu>, gregc@cgl.ucsf.edu writes: > >Does the PEX standard specify how the PHIGS API and X work together? >Specifically, if you want to use X events for input, could you still >use PHIGS for picking? > >The current DEC PHIGS product provides such a method, a pphittest >function to do picking in an PHIGS output-only workstation. And I've >heard that in IBM's graPHIGS, you can pass an X event to the graPHIGS >widget for picking. > >Please tell me that this will be standardized soon. > > - Greg Couch > gregc@cgl.ucsf.edu > I had a little experience with graPHIGS that is IBM's version of PHIGS. It works in AIXwindows enviroment with no problems, in fact not noticing that it is working in the window. You do not have to worry about handling events, it is done by software. Although if you want to handle some events or create some resources yourself, you are free to do it. In manual there is an exaple program showing how to create window using X Toolkit and make graPHIGS use it. /************************************************************************ / _ __ / email: raf@fib.upc.es / / / | __ / / phone: +34-3-4016940 fax : +34-3-4017040 / / /_/ / / -- /-----------------------------------------------------/ / / \ /_/_ / / Disclaimer : / / / / And this is my opinion but I disagree with it. / ************************************************************************/
rthomson@mesa.dsd.es.com (Rich Thomson) (03/02/91)
In article <gregc.667779263@zeno.mmwb.ucsf.edu> gregc@cgl.ucsf.edu (Greg Couch) writes: >Does the PEX standard specify how the PHIGS API and X work together? Input is one of the hardest things to get right in a PEX implementation. The approach of the SI was to support two kinds of workstation types: tool and drawable. The tool workstation type spawns off a process called the "PHIGS monitor" and is intended for PHIGS-literate and X-ignorant applications. The PHIGS monitor handles all X events from the server and handles all PHIGS-style input from the client. The drawable workstation type is for clients that are X-literate and want to handle X events themselves (i.e. if you are using a widget set, for instance). This works just dandy for most of the kinds of input you want except picking. The SI support for picking is in the PHIGS monitor process. I am not sure exactly how they implemented it since I work "above the wire" on the client side of the world. Since the PHIGS monitor portion of the SI wasn't yet available when E&S started offering PEX, we implemented a picking extension to our server that an application could use in conjunction with PHIGS and X-style input. The application would initiate a pick traversal and would receive events based on the result of the pick. The X input extension can also be used to get other kinds of input (dial box, tablet, etc.). >Specifically, if you want to use X events for input, could you still >use PHIGS for picking? I don't believe this will be possible unless you have some other kind of non-SI picking support in your server. I beleive DEC is also supporting this style of picking. >Please tell me that this will be standardized soon. Well, it is "standardized" by PHIGS-style input libraries, but I don't think it will be portable any time soon. Personally, I like the idea of supporting all PHIGS-style input from a compatability perspective, but supporting X-style input from a performance perspective. My feeling is that once the PEX-SI gets out into the real world that people will be unhappy with the PHIGS monitor approach to picking and input and will migrate to PEX/X-literate applications instead of PHIGS only applications. The latter will still be important in moving that software base of existing PHIGS applications to the PEX environment, though. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
pmartz@undies.dsd.es.com (Paul Martz) (03/05/91)
In article <gregc.667779263@zeno.mmwb.ucsf.edu>, gregc@cgl.ucsf.edu (Greg Couch) writes: > Does the PEX standard specify how the PHIGS API and X work together? > Specifically, if you want to use X events for input, could you still > use PHIGS for picking? > > The current DEC PHIGS product provides such a method, a pphittest > function to do picking in an PHIGS output-only workstation. And I've > heard that in IBM's graPHIGS, you can pass an X event to the graPHIGS > widget for picking. > > Please tell me that this will be standardized soon. > > - Greg Couch > gregc@cgl.ucsf.edu In addition to the good points Rich Thomson has already made concerning this issue, I just wanted to add that the PEX protocol itself makes no rules concerning input. It provides some requests to ease the implementation of picking, but how picking is implemented is entirely up to the API library. If your favorite PEX-based PHIGS won't let you use both PHIGS picking and X input events at the same time, that's a restriction the API implementors have made, not the PEX protocol itself. I believe the PEX-SI has indeed made this restriction (i.e., PHIGS input and X input may not be intermixed) but I may be wrong... Anyone from the SI team read this? Marty? Cheryl? Tom? Lisa? Also, FYI, the PEX protocol defines no new events. -- -paul pmartz@dsd.es.com Evans & Sutherland
jch@stardent.COM (Jan Hardenbergh) (03/06/91)
Paul Martz write: > In article <gregc.667779263@zeno.mmwb.ucsf.edu>, gregc@cgl.ucsf.edu (Greg Couch) writes: > > Does the PEX standard specify how the PHIGS API and X work together? > > Specifically, if you want to use X events for input, could you still > > use PHIGS for picking? > > > > The current DEC PHIGS product provides such a method, a pphittest > > function to do picking in an PHIGS output-only workstation. And I've > > heard that in IBM's graPHIGS, you can pass an X event to the graPHIGS > > widget for picking. > > > > Please tell me that this will be standardized soon. > > > > - Greg Couch > > gregc@cgl.ucsf.edu > > In addition to the good points Rich Thomson has already made > concerning this issue, I just wanted to add that the PEX protocol > itself makes no rules concerning input. It provides some requests to > ease the implementation of picking, but how picking is implemented is > entirely up to the API library. If your favorite PEX-based PHIGS won't > let you use both PHIGS picking and X input events at the same time, > that's a restriction the API implementors have made, not the PEX > protocol itself. Even non-PEX based PHIGS products sometimes have an escape for picking. In the next issue of Computer Graphics Forum there is a paper discussing integrating PHIGS and User Interface Systems. The thesis is to ignore the ancient UI technology of PHIGS and to provide for the UI/Application to pick programmatically. > I believe the PEX-SI has indeed made this restriction (i.e., PHIGS > input and X input may not be intermixed) but I may be wrong... Anyone > from the SI team read this? Marty? Cheryl? Tom? Lisa? No, the PEX-SI has an escape for picking - just no man page for it. It is ESCAPE -4. Hopefully, someone wrote the man page it just did not get distributed. > Also, FYI, the PEX protocol defines no new events. At least, not until PEX 6.0. (Workstation initiatated traversal occured). -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742