home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / mac / programm / 18384 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  3.5 KB
  1. Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!usc!wupost!cs.utexas.edu!sun-barr!ames!agate!NewsWatcher!user
  2. From: werner@soe.berkeley.edu (John Werner)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: XVT's Portability Toolkit
  5. Followup-To: comp.sys.mac.programmer
  6. Date: 13 Nov 1992 21:03:15 GMT
  7. Organization: UC Berkeley School of Education
  8. Lines: 62
  9. Distribution: world
  10. Message-ID: <werner-131192125438@128.32.157.31>
  11. References: <17443@mindlink.bc.ca>
  12. NNTP-Posting-Host: 128.32.157.31
  13.  
  14. In article <17443@mindlink.bc.ca>, Daryl Spitzer wrote:
  15. > 
  16. > Does anyone know anything about XVT's Portability Toolkit?
  17. > [...]
  18. > So is this for real?
  19.  
  20. Here's an editied verion of what I answered last time someone asked this
  21. (in comp.lang.c++)...
  22.  
  23. At my last job I was involved in a research project evaluating future
  24. cross-platform projects.  We spent most of our time evaluating and
  25. prototyping with XVT.  One of their current products is also mostly written
  26. with XVT.  So I can give you some opinions.
  27.  
  28. For totally-from-scratch portable development of simple applications, XVT
  29. probably isn't so bad.  Code that's written using just the XVT api is
  30. indeed portable.  The catch is that the API is basically a lowest common
  31. denominator of all the environments it supports.  The people at XVT will
  32. deny this; it's sort of a religious issue with them.  But just try to get
  33. them to support some functionality that isn't directly supported by all the
  34. environments, and you'll find out the truth.  We were trying to get them to
  35. support floating windows and pop-up menus, among other things, and they
  36. refused, basically for religious reasons.
  37.  
  38. What little I saw of XVTs C++ class library made me want to run and hide. 
  39. It was just a set of wrapper classes around the various objects in the C
  40. api.  I spent a fair amount of time writing my own MacApp-inspired C++
  41. library around XVT.  It's possible to do, and it was actually kind of fun
  42. for me, but it's something XVT should have done themselves.  I think
  43. writing a real class library is definitely the way to go if you plan to
  44. write a large user interface with XVT.
  45.  
  46. One more complaint: XVTs resource language is a piece of junk.  It's
  47. impossible to be any more polite about it than that.  It really stinks out
  48. loud.  For all but the simplest applications you'll have to code the
  49. resources separately on each platform.
  50.  
  51. And finally, the programmers at my last job who developed a Windows product
  52. using XVT absolutely HATED it.  Part of this was related to dialog box
  53. support: XVT doesn't have a very complete or flexible set of dialog
  54. functions.  They don't allow you to define custom controls in dialogs at
  55. all portably.  Related to this is the fact that mixing platform-specific
  56. code into an XVT application is a major nightmare; you start running into
  57. lots of "who's in charge" issues, and lots of things that are just plain
  58. XVT bugs.  We had the source code, so at least we could fix them.
  59.  
  60. Summary: If you're writing a simple program, without complicated dialogs,
  61. or if you're willing to take the time to write a large class library around
  62. XVT, it might be worth using.  Otherwise don't.
  63.  
  64. PS: Have you considered writing in MacApp and then porting to Bedrock (the
  65. new portable class library being developed by Apple and Symantec) when it
  66. comes out (sometime next year?)?
  67.  
  68. > (If so, why should one wait for Bedrock?)
  69.  
  70. Bedrock is going to be an entirely different animal: an application
  71. framework/class library, ala MacApp.
  72.  
  73. --
  74. John Werner                         werner@soe.berkeley.edu
  75. UC Berkeley School of Education     510-642-9651
  76.