bill@polygen.uucp (Bill Poitras) (01/21/91)
In article <1991Jan14.211226.17872@isc.rit.edu> cms2839@isc.rit.edu (C.M. Stuntz ) writes: > > XVT ( eXtensible Virtual Toolkit ) from >GSS , will allow you to use a single source code that is protable [stuff deleted] > i've not used any of them , so i can't >attest to their worth . i only know what they claim to do . Can any one out there attest to their worth? Has anyone had any experience with XVT? I would like to know any problems with XVT to see if I can use it for cross platform development. E-mail or post is fine. I will try to summarize what responces I get by e-mail. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | | bill@polygen.com | +-----------------+---------------------------+-----------------------------+
my@dtg.nsc.com (Michael Yip) (01/23/91)
In article Bill Poitras writes: >In article C.M. Stuntz writes: >> >> XVT ( eXtensible Virtual Toolkit ) from >>GSS , will allow you to use a single source code that is protable >[stuff deleted] >> i've not used any of them , so i can't >>attest to their worth . i only know what they claim to do . >Can any one out there attest to their worth? Has anyone had any >experience with XVT? I would like to know any problems with XVT to see >if I can use it for cross platform development. E-mail or post is fine. >I will try to summarize what responces I get by e-mail. I have not use the XVT development system at all, but I read somewhere that the XVT Toolkit only provides an union of the X, Win3 and the MAC capabilities. That is good and bad. If that is true, then the XVT Tool Kit only provide a subset of each window enviornment and not all the functions. It is good, on the other hand, that you have one program source and it works on all environments. Well, that's my 2 cents. -- Mike my@berlioz.nsc.com
nazgul@alfalfa.com (Kee Hinckley) (01/31/91)
> In article <1991Jan14.211226.17872@isc.rit.edu> cms2839@isc.rit.edu (C.M. Stuntz ) writes: > Can any one out there attest to their worth? Has anyone had any > experience with XVT? I would like to know any problems with XVT to see > if I can use it for cross platform development. E-mail or post is fine. > I will try to summarize what responces I get by e-mail. For what it's worth they have a competitor now. A company going by God-awful name (although it was bound to happen eventually) of "Open Inc.". I haven't used XVT. I have reviewed the manual extensively. My firm belief is that virtual toolkits are too limiting and that any commercial app will have to bypass them at one point or another. (A quick survey of about 17 of the apps on my Mac shows that only one does not have some non-standard, application-specific interface object). I do know that there is no way in hell I could have written Poste (our email product) in XVT without going through to the Motif/Xt level. Some of those cases would be due to dealing with Motif bugs/limitations, others just a matter of trying to make the interface more usable; I'm a firm believer in tuning each GUI interface individually. XVT claims their toolkit is not a least common denominator solution. They are partially correct. What they've done is filled in a few of the holes themselves. However you are still abandoning full font control, internationalization, all geometry management other than bulletin boards (and thus you lose user-font control), and a number of other features. Furthermore, the pass through mode may allow you to use missing primitive widgets (e.g. arrow button) however there is no way to use composite widgets, since there is no way to create XVT objects as children of those widgets. All this said, if you can deal with those limitations, or if the speed of porting is more important than the quality of each individual interface, then as far as I can tell, XVT does work and can be used. I don't know about Open Inc.'s toolkit. I've asked them for an API (I just spotted them at Uniforum last week), we'll see what they send. -kee
ctim@dolphin.aaet.ti.com (Craig Timmerman) (02/01/91)
> > In article <1991Jan14.211226.17872@isc.rit.edu> cms2839@isc.rit.edu (C.M. Stuntz ) writes: > > Can any one out there attest to their worth? Has anyone had any > > experience with XVT? I would like to know any problems with XVT to see > > if I can use it for cross platform development. E-mail or post is fine. > > I will try to summarize what responces I get by e-mail. > > For what it's worth they have a competitor now. A company going > by God-awful name (although it was bound to happen eventually) of > "Open Inc.". Just wanted others to know that there is a third competitor in what may be come a big market for generic APIs. The product is called Open Interface and Neuron Data is the vendor. I got a chance to see Open Interface demoed in Neuron's suite at UNIFORUM. What follows is my summary of the demo. Standard disclaimers apply to this summary. I make no guarantees on the accuracy of the information and my apologies to Neuron Data if I have mis-represented any of this information. I'm sure I missed something after talking with Neuron for almost two hours. This summary is only meant to give others a general for the capabilities of Open Interface. If you want the story straight from the horse's mouth contact: Neuron Data 156 University Avenue Palo Alto, CA 94301 (415) 321-4488 NOTE: I abbreviate Open Interface as OIT throughout this document. The trademarked name for this product is Open Interface, but it has been know as Open Interface Toolbox. The OIT abbreviation hopefully avoids the confusion with with Solbourne's trademarked OI-Object Interface toolkit. Overview -------- OIT is a generic API for user interface development. It allows a developer to code his/her application to the OIT API and the resulting application will run, without code changes on multiple window system/OS combinations. The code only has to be recompiled and relinked for this to be accomplished. The resulting OIT application has a runtime switchable look and feel. The application can adapt to the native look and feel or support the same look and feel on all platforms. In addition to linkable libraries, OIT contains an interactive interface builder which generates OIT resource files and C templates. OIT was developed out of a need to provide a portability base for Neuron's expert system products. It has been used in some form for over three years and runs on over 30 platforms. Pre-release customers include Shearson Lehman/American Express, GE Medical, CSX Corporation, and Fusion Systems Group. Neuron stated that IBM paid them to port OIT to the RS6000. The product is in pre-release/beta right now and Neuron plans to formally release by April. OS/Window System Support ------------------------ OIT supports UI development for the following window systems: Macintosh, MS-Windows 3.0, Presentation Manager, DECwindows and X Windows (Motif and OPEN LOOK look and feels will be supported). General operating systems supported are: Macintosh, DOS, OS/2, VMS and UNIX. Specific UNIX platforms supported include: RS6000, Sparcstations, HP/Apollos, Decstations, and SCO UNIX platforms. Neuron was open to porting OIT to any platform -- for a price. Implementation Approach ----------------------- Neuron's implementation approach was to built a virtual graphics machine (VGM) on top of the native window system. Layered on top of this is the actual OIT library and widgets (Neuron uses X terminology when talking about their UI objects). When running on X, the VGM sits directly on top of the Xlib layer. The Xt/Motif/Open Look toolkit layer and corresponding widgets sets are NOT used. Neuron implements its own version of the Motif and OPEN LOOK look and feels (just like Solbourne has done with their toolkit). They plan to be certified as a fully compliant Motif and OPEN LOOK toolkit. When running on the other window systems the VGM is layered on top of Windows, PM and Mac, but they claimed only the basic primitives of those window systems are used. Not layering on top of the Motif and OPEN LOOK toolkits may be seen as a disadvantage to some. I think this overall approach has allowed Neuron to by-pass some of the least common denominator problems associated with other generic APIs (like XVT). Development Process ------------------- Given that OIT has its own API and resource file format it is nice to see that a key part of interface development includes an interactive interface builder called the Layout Editor. The Layout Editor is much like other UIBs in the market today. It allows you to interactively create, position, and set object attributes. A unique part of the Layout Editor is its widget browser. This browser gives you a hierarchical display of all the components in the interface. The Layout Editor generates multiple output files. The first is a resource file. The resource file is basically a textual description of all widgets defined. The second thing is C code templates for interacting with the objects. These templates give you the outline of your application code. The developer must take the templates and fill in the holes, i.e. add specific code for what to do when specific events occur. The third thing generated is the actual makefile. Since the Layout Editor generates C code, any changes the developer makes to the templates must be saved off before re-executing the Layout Editor. This will be a source of extra pain for the developer and a facility to manage code differences would be a nice enhancement to the Layout Editor. The Layout Editor was built with the OIT libraries so it and other related tools (icon/bitmap editor, etc) can be used on all supported platforms. OIT Widgets ----------- The OIT Widget set contains all of the basic widgets one would expect to find in any windowing environment. A couple of widgets were noticeably missing and they were the menubar and pulldown menus. Neuron said these widgets were under development, and would be in the first release. Neuron has added some extra, more complex widgets to their set. The two most notable are a table and network widget. The table widget can be thought of as a generic spreadsheet widget. It gives you variable width rows and columns with the ability to store any type of object in the slots (the closest thing to this in X is the publicly available Table widget). I believe that the network widget got its name from its ability to display expert system networks that Neuron's AI tools needed. It would be more aptly named the graph widget. It can display and manipulate graphs of various types (trees, directed graphs, etc). The only form of graphical object support seems to be drawing areas and iconic buttons. These might work for general rectangular objects, but arbitrary graphical objects do not appear to be supported. There are graphics primitive (e.g. lines, circles, etc), but the graphics cannot be treated as an object unless they are drawn inside one of the existing widgets. OIT widgets are object oriented, and can be subclasses to create new widgets. The Layout Editor can then be extended to comprehend these new widgets. This is a key plus for OIT. However, just because widgets can be subclassed doesn't mean a true object-oriented language is used. OIT and its widgets are written in ANSI C. The subclassing mechanisms sound like those used in the X Window System's Xt toolkit widgets. OIT API ------- The API is multiple libraries of C function calls. Any language that can make C function calls and exchange data with C can be use for application development. All of their libraries are either dynamic link libraries (DOS, OS/2) or shared libraries. The general programming strategy appears to be similar to that of the Xt toolkit. There is an event loop and events are dispatched to the appropriate widget where the application specific functions can be called. Unlike Windows or PM where events are only delivered to windows (not individual buttons, etc) Neuron claimed to dispatch events to the lowest level widget if so desired. This is a big plus to isolated functionality and code reuse in my opinion. If the application needs to it can always go down to the native window system to do something. Of course in X this means using Xlib calls, the higher level Xt toolkit functionality is not there. You can also combine other third party graphics capabilities. For example: Shearson defined a widget where they could perform DataViews graphics into. I asked about C++ and Neuron stated they looked at a re-write about a year ago and C++ was not standardized enough to get a stable development environment on all their supported platforms. They talked about a potential C++ binding layer for OIT. I think this would possible. I have successfully used the C++ bindings for Motif and bindings for OIT would probably be very similar. The main problems with bindings is the C++ object to widget relationship and subclassing objects. With the first, duplicating, copying, and destroying C++ objects must be done carefully. Subclassing to add application specific data/functionality is no problem. However if you want an entirely new widget type, you would first have to subclass the standard C widget then write a new C++ binding for this new class--kind of a two step subclassing scheme. Resource Files -------------- OIT uses resource files to define the static portions of the interface. Changes can be made to the resource file which will not require code to be changed or recompiled. The resource "language" used is proprietary. Neuron claimed to be looking into the ability to translate other resource files (Mac, Windows, PM, Motif UIL) into their format. This would provide a partial form of portability from those APIs to OIT. Customization of resources (i.e. changing colors, fonts, etc) would be up to the application to support. Although they said that simple X resources (via the .Xdefaults file) could be set. No general facility for end-user customization appeared possible. Matching the Environment ------------------------ A key factor in the ultimate decision to use a generic API is: will the resulting application fit into the native environment, i.e. will it look and function like an application developed with a native toolkit? In the OIT's case there are definitely some rough edges that need to be looked at. The implementation I saw was not yet complete. The some widgets did not yet have a completed look and feel, e.g. in the Motif look, the scroll bars did not look like Motif scroll bars. Since Neuron's goal is to be an OSF certified Motif toolkit and a certified OPEN LOOK toolkit, one can assume these minor differences will be fixed. There were similar look and feel differences in OIT's PM look, but the differences didn't seem to be as great. Interaction with other applications may be of greater concern. Windows/PM dynamic data exchange is a feature only available on some systems so Neuron chose not to support it. However, they did state the application could still do DDE by going down to the native window system level (this code would not be portable). How the application would actual receive the DDE messages was not covered (do they come in as OIT events??). OIT applications can deal with the X Windows selection mechanism. This would indicate support for a clipboard cut and paste capability which all window systems have, but is not as dynamic as DDE. Internationalization -------------------- I didn't really get much information on this (or I forgot it). Neuron's marketing literature shows OIT with Kanji text and claims two-byte character support in OIT. Documentation ------------- Documentation does not exist at this time. A draft of the programmer's manual should be available sometime in February. Right now the only way to get more details on how OIT is used is to attend Neuron's training class. Pricing ------- Open Interface is certainly not the cheapest development/delivery system on the market. For quantity one the pricing is: Development systems DOS PC and Mac $7,000 OS/2 systems $9,000 UNIX systems $12,000 Runtime systems (think of it as a per system royalty) $1000 per system Neuron seemed very flexible as to pricing. Seemed like everything could be negotiated, especially the runtime fees and network licenses. They said runtime pricing for developers of low cost "shrink-wrap" applications would be much lower. Conclusions ----------- IMHO, Open Interface is the best thing I have seen that attempts to solve the common API problem. OIT seems to be much more object-oriented that other approaches and the similarities to the Xt toolkit would make it more comfortable to those who work with X. Pricing will probably be a major stumbling block for a lot of developers. Maybe if enough interest is generated, Neuron would reconsider the runtime charges. ---------------------------------------------------------------------- Craig Timmerman ctim@aaet.csc.ti.com Texas Instruments Austin, TX ----------------------------------------------------------------------