zee@fwi.uva.nl (Daniel M. van der Zee (I89)) (06/24/91)
Some time ago I posted a message on netnews requesting information about
XVT, a package for x-developing the same application on multiple platforms with
a graphical user interface (GUI). A lot of people asked me to post a summary or forward the replies I got. So, this is the summary.
My initial message contained nine questions covering some topics I was
interested in. Four people replied and mailed me some very useful info. If i get more replies later, I`ll update the summary.
I will not include names or e-mail adresses of the people that have send me
information, but if you would like to contact those people directly mail me and i`ll ask 'm if its OK.
Throughout this document you`ll see lines starting with a ">". Those lines
indicate that you're reading a part of my original posting. If i get more
replies later I`ll update the summary.
You can contact the creators of XVT at:
XVT Software, Inc.
Box 17665
Boulder, CO 80308
(303) 443-4223
(303) 443-0969 (FAX)
-------------------------------------
>About two weeks ago i posted a message about x-developing the same app for
>mac, x & ms windows. I got a lot of replies suggesting i should take a look
>at XVT. The only thing i know about XVT so far is that it is a
>collection of header files and libraries that create a layer between the
>operating system of various GUIs and my program.
>What i fear is that to use XVT i have to learn to program yet another
>operating
>system from the ground up. (I well remember the horror of trying to understand
>the first three issues of Inside Macintosh). I would like to have some more >info about XVT before actually looking at it myself.
>If you have some time left and you've used XVT yourself i would appreciate
>some answers to the questions below
>(for most questions a simple Yes or No will do):
If you call them they will send you a very comprehensive packet of
information. I've heard alot of good things about it. It is pretty
expensive, though, but it does give you real portability.
--
BTW, let me say one thing before I start. I've programed in both XVT
and the Mac Toolbox. XVT is by far much easier to learn. For one thing,
there's only one manual, instead of 6 ! And a lot of the low-level
grunge work that you have to do in writing a Mac Native application is
taken care of by the XVT layer. Fer instance, if you just need to write
a simple yes/no Dialog box, its a one line call in XVT.
--
Before answering your questions here's a brief introduction:
XVT, the Extensible Virtual Toolkit, provides
a single application interface to multiple window system platforms.
These include the Macintosh, Microsoft Windows on DOS, Presentation Manager
on OS/2, X/Motif (on Sun 680x0, Sun SPARC, Interactive 386/ix, SCO XENIX,
IBM RISC 6000, VAX DECstation, HP9000, VAX VMS), X/OPENLOOK (to be shipped
later this year), AND character terminals on DOS and UNIX. XVT gives you
the potential to have a single body of source code which is portable across
all of the supported platforms.
XVT provides windows, menus, dialog boxes, buttons, list boxes, graphics, and
keyboard and mouse input (plus much more). All of these capabilities are
implemented on all platforms, (except graphics is obviously limited on the
character based systems). XVT is NOT the least common set of window features
across all platforms. It is a set of abstractions to window system programming
which are implemented on each platform.
In the cases where XVT can not meet all the needs of a program on a particular
platform, XVT enables the programmer to extend the application's capabilities
by accessing the native window sytem components of XVT objects. Hence, the
term "Extensible." In general, the full capabilties of the native window
system are available in non-portable ways, including handling all native
system events.
======
>1 Is XVT just a collection of "low-level" functions that translate the params
> to the OS its running on?
Yes ... about the same level as Windows or Mac API.
--
More or less. It "virtualizes" a new API on top of the system its running
on. Depending upon the idiosynchrosies of the particular toolkit your
running XVT on top of, and how well that particular toolkit meshes with
the rest of the world, XVT will look more or less like that particular
toolkit. Does that make any sense ? In other words, the XVT folks have
done as little translation as they can get away with. In some cases, they
have to do more to arrive at a virtual API that can be shared by all
the windowing systems. In other cases, they do much less. XVT was
writtin first with the Mac and MS Windows in mind, though, so I'd say
the API is probably closer to those systems than any others.
--
XVT is a layer between the application and the native window system.
The window system is usually a layer on top of the OS. (In the case of
the Mac, there is not clear distinction between OS and window system.)
XVT is best thought of as a set of window system abstractions (windows,
events, drawing functions) which are used in programming applications with a
GUI. On some platforms an abstraction has a direct correspondence to
the native window system, so an XVT function translates very simply to
a native window system function; however on other platforms, the same
abtraction may not exist, so XVT implements it in its layer
======
>2 Does XVT contain a large class library for speeding up application
> development? (if so how does it compare to MacApp)
> Is it good? (does XVT speed up application development for applications
> that will have to run on one platform only?)
There is a class library, XVT++, which is in advanced beta testing (and
available). I don't know how good it is.
--
XVT is not object-oriented, and is in vanilla C, so it doesn't have a
"class library" per se. (I believe they are coming out with a C++
version, put I don't know anything about it). As I mentioned above,
the API and function calls you make to XVT tend to be, IMHO, at a
"higher level" than the equivalent calls in the Mac Toolbox, though,
so I'd say its faster to right an XVT application than to write the
same application in the native toolkit.
--
XVT does not use a class library concept, although on some platforms there
is a direct correpsondence between XVT abstractions and classes in the
native window system. However, the abstractions are well chosen, and XVT
does indeed speed up development on each platform, as compared to developing
in the native window system or toolkit. For example, I prototype applications
on a Mac which ulitimately are meant to run on a Sun sparc station using the
Motif toolkit on X. I know very little about Mac OS or window system
internals, yet I have created several Mac applications quickly.
======
>3 Does XVT cover more than the parts all GUIs have in common or does it try
> to add good things from one GUI to the other?
I'd say mostly the common parts, with some good stuff.
--
I don't think it really adds things from one GUI to the other. In fact,
I think the opposite is probably true. XVT is written first and foremost
with cross-platform compatability in mind - sometimes you lose some
of the nifty features of one particular GUI because its not available in the
others, and there's just no way to virtualize it. Of course, you can
always "drop down" from the XVT level to make calls in the native
GUI's language, but you're giving up cross-platform compatibility as
soon as you do that....
--
XVT is much more than a collection of least common features, it has added
several well chosen features.
======
>4. Has printing be implemented?
> How hard is printing (compared to mac)
Printing is there. I don't remember Mac printing techniques, but it seems to
be comparable to Windows.
--
Yes, both printing and file i/o have been implemented. Unfortunately,
I'm not really up on printing on both the Mac sides and the XVT side,
so I don't really feel qualified to judge which is easier.
--
XVT does include printing in its abstractions. An application
simply opens a print window, draws into it using the
same code for drawing into a screen window, and closes the print window.
(There are some details about starting and ending a page which
are not part of screen drawing that must be handled.) But in general,
you draw to the printer the way you draw to a window. This is a great
bonus for XVT on X, since there is no printing functionality in X lib
or any of the Intrisnics based toolkits.
======
>5. Has a text-edit object been implemented?
Yes, text edit has been implemented. I believe you can only have
one font per object. While I can't find it explicitly in the doc,
I almost bet that since XVT TextEdit is based (on the Mac) on Mac
TextEdit, you have the same limitations you would have in the Mac
Toolbox.
> Can it handle multiple fonts in one object?
No, but this may change soon. Check with XVT for details on this in
the next release (Release 3).
> What is the limit to the number of chars in such an object?
Implementation dependent. I'm not sure but the limit is probably the
number of characters that can be addresses with an unsigned short.
> Are there any other limitations?
That depends on your needs. In general, the XVT text edit object is a very
flexible "editor in a rectangle" which features such as:
insert or manipulate text from the application; enable/disable user editing;
control whether text is wrapped or not; include borders or not; limit
number of characters per paragraph or whole object (useful for forms entry);
enable/disable cut, copy, and paste; enable/diasable scrolling;
and all attributes can be changed dynamically.
======
>6. Are resource definition files translated to all GUIs?
Yes
-
This used to be a weak point in XVT, in that you had to
basically define the resource files seperately on each GUI.
In the latest version, though, XVT uses a resource language of
its own design, called URL (universal resource language). You
define your resources in that language, and compile them into
a native resource language using a supplied compiler. On the
Mac, the URL compiler spits out and Rmaker script, which you
can then compile with Rmaker into a Mac resource file.
--
Yes, currently this is done through a text file which describes the
XVT resources and is compiled into the native resource description.
Later this year a graphical resource editor for doing this will be released.
======
>7. What are the strengths of XVT?
Portability, portability and portability. Price is also OK ... $800 for a Mac
or Windows version.
--
Cross platform compatibility and a relatively easy to learn API
(beats the heck out of learning both the Mac toolbox *and*
MS Windows or PM). An additional benefit is the help system you
can include in your application - it literally no harder than
dumping MS Word text through a (yet another) compiler, and including
a call to the help system when your user generates a request for
help. Although it doesn't use the system 7 help menu yet, I wouldn't
be suprised if the XVT folks didn't have that working in short order..
--
By far, the greatest strength is portability of programs across multiple
window system platforms. The second greatest strength is the capability
of developing GUI programs quicky for each of the supported platforms.
======
>8. Is there something you cannot do with XVT?
Font handling leaves something to be desired, so I wouldn't try to write a
word processor using XVT.
-
Sure, lots of things. You can write a pretty full feature application
in XVT, but you ain't gonna be able to use a lot of fancy features that
are cutting-edge on the particular system your working on. For instance,
I wouldn't expect to see balloon-help any time in XVT. You didn't use
to be able to create a floating pallette like the hypercard tools pallette
in XVT, though to be honest with you, they keep adding functionality
everytime I look and it may be in there now...
Of course, you can always sacrifice cross platform compatibility and
go below the XVT level, though. I must admit this can be a bit of a
pain - the XVT manual doesn't give you a lot of clues as to how the
XVT data structures/system calls relate to the ones in the native
toolbox - sometimes you have to do a little sleuthing in the header
files to figure out how to mix XVT calls and native toolbox calls..
--
Some things aren't easy, but the entire capabilities of the native window
system and native OS are always available if they are needed.
======
>9. What compilers does XVT work with?
ThinkC and some other Mac compiler; most Windows-compatible C compilers.
-
On the Mac, Think C Ver 4.0 or later, MPW and MPW C 3.0
On Windows, Microsoft C version 5.10 (If there are later versions,
it may work on them but the manual I have only lists that version)
--
XVT supports most of the major compilers for each platform XVT runs on.
======
>(Please excuse my english and ignore my spelling errors)
again
-------------------------------------------------------
For questions feel free to contact me:
Daniel van der Zee
Student Computer Science
University Of Amsterdam
The Netherlands
e-mail: zee@fwi.uva.nlbill@polygen.uucp (Bill Poitras) (06/28/91)
In article <1991Jun24.150205.21341@fwi.uva.nl> zee@fwi.uva.nl (Daniel M. van der Zee (I89)) writes: >>5. Has a text-edit object been implemented? >Yes, text edit has been implemented. I believe you can only have >one font per object. While I can't find it explicitly in the doc, >I almost bet that since XVT TextEdit is based (on the Mac) on Mac >TextEdit, you have the same limitations you would have in the Mac >Toolbox. I can guarentee that you would lose that bet. XVT has created its own TextEdit object. In fact you can license the source from them for just the textedit object. I talked to them in March and they considered using the native toolkit's textedit object as the basis for their, but for now that is not true. > >>6. Are resource definition files translated to all GUIs? >Yes One more thing to add: the URL resource system is capable of converting native resources into URL, for coversion to another format. e.g. design dialogs on the Mac, run them on Motif. >====== > >>8. Is there something you cannot do with XVT? >Font handling leaves something to be desired, so I wouldn't try to write a >word processor using XVT. This has been improved in XVT 2.1 on most platforms. This new feature is called the 'font mapper'. What you do is describe the font (face, style, size, best font for printer or screen) and the function returns the closest font that it can find. This is much like the logical font handling in Windows. The feature exists on Mac, Windows, and Presentation Manager. > >On Windows, Microsoft C version 5.10 (If there are later versions, >it may work on them but the manual I have only lists that version) Also Borland C++ for XVT/CH, and I don't know if it out yet, but XVT/Win is going to have Borland C++ compatibility too. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton bu}!polygen!bill | | (bill) | Waltham, MA USA | - This space for rent - | | | FAX (617)890-8694 | bill@polygen.com | +-----------------+---------------------------+-----------------------------+