From: werner@soe.berkeley.edu (John Werner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: XVT's Portability Toolkit
Followup-To: comp.sys.mac.programmer
Date: 13 Nov 1992 21:03:15 GMT
Organization: UC Berkeley School of Education
Distribution: world
NNTP-Posting-Host: 128.32.157.31

In article <17443@mindlink.bc.ca>, Daryl Spitzer wrote:
> 
> Does anyone know anything about XVT's Portability Toolkit?
> [...]
> So is this for real?

Here's an editied verion of what I answered last time someone asked this
(in comp.lang.c++)...

At my last job I was involved in a research project evaluating future
cross-platform projects.  We spent most of our time evaluating and
prototyping with XVT.  One of their current products is also mostly written
with XVT.  So I can give you some opinions.

For totally-from-scratch portable development of simple applications, XVT
probably isn't so bad.  Code that's written using just the XVT api is
indeed portable.  The catch is that the API is basically a lowest common
denominator of all the environments it supports.  The people at XVT will
deny this; it's sort of a religious issue with them.  But just try to get
them to support some functionality that isn't directly supported by all the
environments, and you'll find out the truth.  We were trying to get them to
support floating windows and pop-up menus, among other things, and they
refused, basically for religious reasons.

What little I saw of XVTs C++ class library made me want to run and hide. 
It was just a set of wrapper classes around the various objects in the C
api.  I spent a fair amount of time writing my own MacApp-inspired C++
library around XVT.  It's possible to do, and it was actually kind of fun
for me, but it's something XVT should have done themselves.  I think
writing a real class library is definitely the way to go if you plan to
write a large user interface with XVT.

One more complaint: XVTs resource language is a piece of junk.  It's
impossible to be any more polite about it than that.  It really stinks out
loud.  For all but the simplest applications you'll have to code the
resources separately on each platform.

And finally, the programmers at my last job who developed a Windows product
using XVT absolutely HATED it.  Part of this was related to dialog box
support: XVT doesn't have a very complete or flexible set of dialog
functions.  They don't allow you to define custom controls in dialogs at
all portably.  Related to this is the fact that mixing platform-specific
code into an XVT application is a major nightmare; you start running into
lots of "who's in charge" issues, and lots of things that are just plain
XVT bugs.  We had the source code, so at least we could fix them.

Summary: If you're writing a simple program, without complicated dialogs,
or if you're willing to take the time to write a large class library around
XVT, it might be worth using.  Otherwise don't.

PS: Have you considered writing in MacApp and then porting to Bedrock (the
new portable class library being developed by Apple and Symantec) when it
comes out (sometime next year?)?

> (If so, why should one wait for Bedrock?)

Bedrock is going to be an entirely different animal: an application
framework/class library, ala MacApp.

--
John Werner                         werner@soe.berkeley.edu
UC Berkeley School of Education     510-642-9651
Newsgroups: comp.sys.mac.programmer