🚀 go-pugleaf

In article <kbo.717941415@helferlein> kbo@rob.cs.tu-bs.de (Karin Borm) writes:
>
>I wrote a 2d-application with SunPHIGS on a Sun-Workstation (SunView!).
>avoiding the programming interface to Sunview.
>Even the menues were realized in PHIGS as workstations with
>pickable graphical elements.

  You have taken the most painless path from SunView/SunPHIGS to
  X/PEX/(Sun)PHIGS.  Congratulations on having fine foresight (or
  else listening to our advice! 8-)!

>Now I try to transfer my application to X-Windows (X11R5) also without 
>using the Xlib or a X-Toolkit.

  BZZzzzT!  Now you're trying to make it MUCH harder on yourself....
  Read on....
  
>I've got two PEX-Versions: the first one was delivered with X11R5
>(1991 by Sun Microsystems, Inc. and the X Consortium),
>the second (newer one)
>is on export.lcs.mit.edu and is called Xpex which I didn't use so far.

  "Xpex" is not a PHIGS library and hence porting your existing application
  to it would be even harder than porting it to MIT PEX-SI PHIGS (which is
  the other one to which you refer.  It is a part of the complete PEX-SI
  which was released with X11R5.)

>The main problem was that almost every phigs routine had a different name. 
>So I wrote an include file with #define`s to correct it.  

  Oh I wished that you would've asked first!  It's not that hard!
  Read on....

[All kinds of problems and woes deleted for brevity.]
>
>Questions:
>
>1. My PEX (first version) has some bugs. Where can I get bug-fixes?
>
>2. Where can I get filters (SunPHIGS<->PEX, SunPHIGS<->Xpex,...)? 
>
>3. Who has experiences using different PEX-versions? What problems/
>   advantages/disadvantages do they have? 

  [Caution: You're referring to "PEX" above as if it were an API.  It is not.
  We prefer to refer to a graphics API as being "PEX-capable" to indicate
  that it is a client library which can communicate with a PEX-extended
  server.  The PEX Sample Implementation (PEX-SI) which was released with
  X11R5 contains a PEX-capable PHIGS API which has a C language binding.]

  The path of least resistance from your *original*, SunPHIGS 1.x
  application source is to get SunPHIGS 2.0, which is not only X-based
  for use with any X11-based server, such as Sun's OpenWindows (as opposed
  to your SunWindows-based SunPHIGS 1.x code), but SunPHIGS 2.0 is *also
  PEX-capable itself!*

  SunPHIGS 2.0 provides scripts which will assist with the conversion
  from SunPHIGS 1.x to 2.0 .  (We've found that the scripts completely
  handle the conversion by themselves in every case tried thusfar.
  We've also found that the conversion for SunPHIGS is considerably less
  involved than that from SunView to Xview, and you've saved yourself
  that additional work by your existing code design.)  The SunPHIGS 2.0
  product documentation will explain how to use the conversion scripts.

  Once you've gotten your source ported over to the newer ISO PHIGS C
  binding you may either leave it as is and continue to use SunPHIGS to
  generate PEX (to any PEX5R1-compatible server which supports the PEX
  Workstation subset.  This includes the X11R5 PEX server on most any
  system, Sun's SunPEX 1.0 product for X11/NeWS, and several of the PEX
  terminals available today.)  Keeping your code SunPHIGS-based will
  assure that your menu-generating SunPHIGS calls continue to operate.

  If you choose the other path -- porting your SunPHIGS 2.0-based source
  to the MIT PEX-SI PHIGS -- you're still in luck, but less.  The SunPHIGS
  2.0 C binding is a superset of the PEX-SI PHIGS C binding.  The port to
  SunPHIGS 2.0 helped you because the C binding for SunPHIGS 2.0 is the
  same as the MIT PEX-SI PHIGS, so you'll only have to deal with any Sun
  extensions that you've used (like the menu stuff.  That is not supported
  in the PEX Sample Implementation PHIGS so you'll have to port those
  portions by re-writing them to your favorite input toolkit and disabling
  the PHIGS input (process).)

  Either way should should go through a port to SunPHIGS 2.0 .

			     > Whew! <

  - Marty Hess    (415) 960-1300    <marty.hess@Eng.Sun.COM>
    Graphics Interface Technologies  --  Manager of PEX Projects
    Sun Microsystems, MTV-23-205, 2550 Garcia Ave, Mountain View, CA 94043-1100

  P.S. Of course, if your intent really *is* to port away from a PHIGS API
  to another API like PEXlib (or PEXlib-like, such as Xpex) then forget all
  this and go back to what you were doing, but wait for the forthcoming
  PEXlib release from MIT!