gwu@tcs.com (George Wu) (03/09/91)
-
This is the summary of responses I received to my earlier (long ago)
request for information and experiences concerning use of Motif in a C++
application. Some of the information is drawn from a regular FAQ posting on
comp.windows.x.motif, which may have more detailed and up-to-date information.
I have stripped out stuff such as mail headers, but there is still some
duplication of information. I was thinking of making this another FAQ posting,
but I think the existing Motif posting suffices. Thanks to all the folks who
responded.
As for the particular approach we've taken, we're using an encapsulating
C++ interface to Motif that was developed in-house for an earlier project.
Since the compiler used then was GNU's, which doesn't check function prototypes
for calls to ordinary C functions, we added the prototyped header files from
WWL. This allowed us to switch to Saber C++, which I've just begun using. So
far, I like Saber, but I'm still doing the port. I also have to port to an
HP9000/300, so I'll get to use HP Softbench too. I will post a comparison of
the two to comp.lang.c++ when I get a chance.
George
##############################################################################
From: Flavio Rose <frose@synoptics.com>
This is in response to your posting in comp.windows.x
regarding C++ and Motif.
I've used C++ with Motif 1.0.x. You need to make your own
versions of all the include files (both Xt and Xm). The
major reason for this is that, in the standard Motif 1.0.x
include files, many functions which take parameters are
declared without them, like this:
extern int foo();
There's also the fact that Xt uses the C++ reserved word
"class" as a field name in a struct.
The exercise of creating the new include files takes a
couple of days, depending on how skilled you are with text
processing tools which could partially automate it.
I haven't started using Motif 1.1. The include file
munging ought to be easier there, however, because Motif
1.1 can use X11R4 Xt include files which have already been
made C++-compilable.
Yours truly,
Flavio Rose
SynOptics Communications, Inc.
##############################################################################
From: Jeff Francis <jfrancis@umaxc.weeg.uiowa.edu>
I'm currently working on just such a project. The two major problems
we've run into are that 1) Motif/X headers are not C++able and 2)
you always need to use static member functions for callbacks.
The first problem was simple to fix, we simply added some extern "C"s,
some ANSI prototypes, and changed a few field names (like one called "class")!
The second problem screws-up the way one needs to look at application
code and user interface code. In our case we have some classes that
have some user interface callbacks and at the same time some "application"
methods. So, with one class we have four "things" sitting around - the
class itself, the class static fields, class static member functions,
and a instance of the global.
Also, another group here developed a C++ "wrapper" library. We've looked
at it, WWL and the Lowell C++ stuff and came to the conclusion that they
all add little or no "behaviour" to Motif and only make it easier to
access a resource field. We decided against using any of these libraries
because of the cost in code size/speed was to great. (And it's just another
thing to learn!)
##############################################################################
From: Jeff Francis <jfrancis@umaxc.weeg.uiowa.edu>
gwu> Could you describe these (WWL and Lowell classes) briefly. I had heard
gwu> about the Lowell work, but didn't realize they had actually released
gwu> anything yet. Where can I get more information, or even the source code?
I think the U of I has a site deal with OSF for Motif. I don't think
the Lowell stuff is generally available. I would contact OSF for more
info.
Both of these libraries "wrap" a widget in that they turn a widget into
an object. So, you can define an object and message it:
XMBulletinBoard aBB(parent object, ...etc)
aBB.get_ResourceName or,
aBB.set_ResourceName.
-jpf
-------------------------------------
Jeff Francis
CS Student, University of Iowa
jfrancis@umaxc.weeg.uiowa.edu
-------------------------------------
##############################################################################
From: ken@tucana.csis.dit.csiro.au
We're programming exclusively in C++ and have no problems with Motif at
least not problems due to the interaction of Motif and C++. It works no
worse and no better than from C. I should also mention we are using
Jean-Daniel Fekete's Widget Wrapper Library to make life easier for
ourselves. It's free and worth it.
Unfortunately we're using Motif 1.0 and still waiting for 1.1 sources.
We'd also like a better environment than g++ and gdb so we're waiting
for Sabre C++.
##############################################################################
From: ken@tucana.csis.dit.csiro.au
ken>I should also mention we are using
ken>Jean-Daniel Fekete's Widget Wrapper Library to make life easier for
ken>ourselves. It's free and worth it.
gwu> Do you know where I can get a copy here in the States?
Here's the info from the Motif FAQ:
Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
It is intended to simplify the task of C++ code writers when using the Toolkit
by providing them with C++ objects, methods, type checking and several utility
functions and classes.
WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and 7.0
and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
other UNIX systems without too many problems.
WWL is distributed as a tar file with all the source, documentation and
example. The file is available using anonymous ftp from
expo.lcs.mit.edu (18.30.0.212 contrib/WWL-1.0.tar.Z
lri.lri.fr (129.175.15.1) pub/WWL-1.0.tar.Z
gwu>Unfortunately we're using Motif 1.0 and still waiting for 1.1 sources.
ken> Motif 1.1 is available from OSF. It's just if you want to use a
ken> vendor supported version that you need to wait. For instance, we're
ken> waiting for HP to release 1.1.
Yes, we sent in all the paperwork and we're waiting for OSF to send it
to us. Sigh...
ken> We'd also like a better environment than g++ and gdb so we're waiting
ken> for Sabre C++.
gwu> Definitely. Saber currently has systems for Sun-3s and SPARCstations
gwu> out, which we've already gotten. We're waiting for HP versions, but they
gwu> tell us that won't happen until May. HP's Softbench environment looks
gwu> great, but it's roughly twice the cost. Other than those two, I haven't
gwu> really found anything as functional. ObjectWorks from ParcPlace is
gwu> certainly far behind.
Good to hear that other people like Sabre C++. This increases my desire
to push for getting a copy.
##############################################################################
From: taipan!zardoz!don@uunet.UU.NET (Don Dewar)
don> X++ widget wrapper libraries like the one out of Lowell
don> are ok, but you don't get the full benefit of C++ when using them.
gwu> I've seen references to the Lowell work, but I've never had a chance to
gwu> take a look at it. Do you know how I could get a copy or more
gwu> information?
don> >From the Motif FAQ
The University of Lowell has a C++ binding. The software is available
on any system running X11R3. Currently it is available for both the GNU's C++
compiler g++ v 1.37.1 and the AT&T C++ v 2.0 translator. The software is
available through either ftp or a 9 track reel magnetic tape for $250. A
license must be purchased first. For additional information and license forms
contact :
University of Lowell
Graphics Research Laboratory/Motif
Computer Science Department
One University Avenue
Lowell, MA 01854
attn : Fran Ward
(phone 508-934-3628)
##############################################################################
From: Rob Sartin <sartin@hpisqm.cup.hp.com>
I'll only address the HP's since that's where I've done this stuff.
This is not an official response from Hewlett Packard.
gwu> Has anyone out there used Motif extensively from within C++ code? I'm
gwu> starting just such a project, and would like to hear of other people's
gwu> experience. Any bugaboos to avoid? Any war stories?
Well, the first thing you'll need is C++ compatible header files. If
you're using HP's on the HP, they come with the compiler.
The biggest problem is that if you're using C++ to implement an object
oriented design, you will quickly be exposed to the hackery it took MIT
to get Xt (and HP to get the Motif widgets) implemented in C. Things
you wish used inheritance, don't. I found myself implementing a whole
class hierarchy to sit between C++ and Xt/Motif. Lots of one line
callbacks that destroy type safety by casting caddr_t client_data to
being a pointer to some object and calling a method on the object. I
wound up with something akin to InterViews (which by contrast to Motif,
was a delight to use from C++) Interactors sitting there as the objects
that interfaced between my software and the Xt/Motif stuff.
If you're willing to sign up for that work, things come out looking
reasonable, but no matter what you do, parts of the code will be
horrible.
Rob
##############################################################################
From: lance.norskog <lance@motcsd.csd.mot.com>
There's something called THINGS on some of the public archives.
This is a class library that works over Motif or Open Look.
It was written at Rome Air Force Base in New York by the SAC
(the nuclear bomber agency)! It's freeware.
Good luck, and say hello to John Mathon for me.
Lance Norskog
##############################################################################
From: Brad Ahlf <bla@hpcupt1.cup.hp.com>
gwu> Has anyone out there used Motif extensively from within C++ code? I'm
gwu> starting just such a project, and would like to hear of other people's
gwu> experience. Any bugaboos to avoid? Any war stories?
HPC++ ships the Motif header files (and X11 and HP-UX header files) for use
with HPC++. Many persons have used them successfully and happily. The
only complaint has been that there are occasional missing function
prototypes for obscurely documented X functions. Those are easily
remedied, of course.
gwu> Experiences with any platform and software combination will be
gwu> appreciated. I'll be working primarily on SPARCstations, but the final
gwu> target is an HP 9000/300. Other software parameters include Saber C++
gwu> (for development on the Suns), and both Motif 1.0 and 1.1. The HP
gwu> compiler will probably be HP's compiler, ie. at least AT&T Cfront 2.0
gwu> compliant.
HPC++ ships on both S300 and S800 platforms with full header filesets.
I am biased, but I believe that HPC++ is the best cfront implementation
available on any platform. It certainly has the best debugging features.
Motif 1.1 fixes lots of 1.0 bugs.
I think you will be pleased with HPC++. HPC++ 2.0 has been shipping for
a long time (since mid-90) and HPC++ 2.1 can be ordered now and will be
shipping very soon (February?). HPC++2.1 for S800 is also a 'true'
copmiler based on cfront. HPC++2.1 for S300 is still a translator, but
a 'true' compiler for S300 will soon follow.
I have heard that Saber C++ is a good environment. It will also be on
HP soon (so I have been told). In addition, there is another good C++
environment on HP (C++/SoftBench) which you might consider.
Brad Ahlf
bla@hpda.hp.com
This response does not represent the official position of, or statement by,
the Hewlett-Packard Company. The above data is provided for informational
purposes only. It is supplied without warranty of any kind.
##############################################################################
From: gmdzi!baecker%f3svb (Andreas Baecker)
We are using Motif extensively from C++. There are NO war stories to tell.
(BTW, what's a bugaboo ?). We are using Motif 1.1, SPARCstations, ATT Cfront
2.0 and GNU emacs with C++ editing mode and we're really satisfied with it.
We have developped (yet another) C++ encapsulation for Motif, an application
framework for Motif and we have several (small) demo applications running,
including a graphic editor.
We are planning to make the C++ encapsulation publicly available soon. If
you're interested, i could mail you the source code.
Andreas
=============================================================================
Mail: Andreas Baecker
GMD (Gesellschaft fuer Mathemathik und Datenverarbeitung mbH)
(The German National Research Center for Computer Science)
Schloss Birlinghoven
D-5205 Sankt Augustin 1
Germany
email: baecker@gmdzi
PHONE: +49-2241-142078
FAX : +49-2241-142618
==============================================================================
##############################################################################
From: jdf%FRLRI61.BITNET@CUNYVM.CUNY.EDU
Try to use the Widget Wrapper Library I wrote, available on expo.lcs.mit.edu
and lri.lri.fr, the first in contrib/WWL-1.1.tar.Z, the second in
pub/WWL-1.1.tar.Z. It is an almost full binding of C++ class to use with
motif. Some issues are explained in the README file included.
There are some problems in any case which are more or less solved in the
WWL distribution.
___ 0 Jean-Daniel Fekete uucp : jdf@lri.lri.fr
/ \ / LRI - Bat 490 bitnet: jdf@FRLRI61.bitnet
/ _/ / Universite de Paris-Sud voice : +33 (1) 69 41 69 10
/__ \/ F-91405 ORSAY Cedex +33 (1) 69 41 66 29
##############################################################################
From: eric%bnrmtl.UUCP@Larry.McRCIM.McGill.EDU (Eric Brunelle)
We have used g++ 1.37.2 with Motif 1.0 on X11R4 (yes, R4) without any
problems, except the libg++ malloc that we had to take out (a simple
flag to turn on in the libg++ Makefile). We used both Sun-3s and Sparcs.
Our work was not extensive though, so mileage may vary.
----------------------------------------------------------------------------
Eric Brunelle | "C'est la nuit qu'il est beau
| de croire a la lumiere"
eric%bnrmtl@iro.umontreal.ca | -- Rostand, Chantecler
----------------------------------------------------------------------------
##############################################################################
From: ian@research.canon.oz.au (Ian Daniel)
For starters ... there are two C++ bindings for Motif ...
Subject: 31)* Is there a C++ binding for Motif?
Answer: The university of Lowell has a C++ binding. The software is available
on any system running X11R3. Currently it is available for both the GNU's C++
compiler g++ v 1.37.1 and the AT&T C++ v 2.0 translator. The software is
available through either ftp or a 9 track reel magnetic tape for $250. A
license must be purchased first. For additional information and license forms
contact :
University of Lowell
Graphics Research Laboratory/Motif
Computer Science Department
One University Avenue
Lowell, MA 01854
attn : Fran Ward
(phone 508-934-3628)
Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
It is intended to simplify the task of C++ code writers when using the Toolkit
by providing them with C++ objects, methods, type checking and several utility
functions and classes.
WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and 7.0
and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most other
UNIX systems without too many problems.
WWL is distributed as a tar file with all the source, documentation and example.
The file is available using anonymous ftp from
expo.lcs.mit.edu (18.30.0.212 contrib/WWL-1.0.tar.Z
lri.lri.fr (129.175.15.1) pub/WWL-1.0.tar.Z
I ahave the doco and license forms for the Lowell bindings, if you can't
get them from the above address (which will probably be quicker than I can
do it).
Question: will you be, or are you considering, using InterViews?
If so, I'm very, very interested in what you find out.
We are about to get in Saber-C++ here, so I'll let you know how it goes.
Good luck.
Ian Daniel
Canon Australia
##############################################################################
From: Jolly Chen <jollyc@hpwarf.wal.hp.com>
This is in response to the note your posted asking about people's
experiences of using Motif and C++.
We're building a large clinical application in C++ and is now beginning to
migrate to a Motif-based interface. We evaluated the University of Lowell
Motif C++ bindings and found them to be inadequate. Currently, our
approach is to mix in Motif calls in our C++ code. Since we're using an
interface builder that generates code, we don't actually write much widget
creation code. What we've do instead is to group all widget creation code
inside a single member function so we can easily import the code generated
from our builder. Callbacks are more of a problem. Our solution is to
make callback functions non-member functions that are friends to our data
object. They need to be non-member functions because member functions
implicitly take the this pointer as the first argument. We then pass in
our data object as a clientData to the callback. In the way, the callback
function can cast the clientData from caddr_t to the appropriate class type
and invoke member functions as necessary.
So far things are working out fairly well. The real solution to this
problem seems to be a C++-based Xt and Motif implementation. A C++
implementation would remove the need to play games with C structures in
attempts to make them look like objects. A C++ implemementation would make
it subclassing widgets a lot cleaner.
Hope that's helpful. Please let me know if you have further insights or
comments.
By the way, I recently asked a similar question, i.e. C++ with Motif, at
the OSF/Motif Bird of a Feather session at the X Conference. Alas, no one
responded with actual project experiences. Comments like "you should
consider InterViews" were not very helpful.
Jolly Chen
Clinical Information Systems
Hewlett-Packard
Waltham, MA
jollyc@hpwarf.wal.hp.com
##############################################################################
Just a brief note here, InterViews 3.0 is now available as an alpha
release. It is obtainable via anonymous FTP from interviews.stanford.edu .
The Quest Systems version of InterViews is a commericial product based on
Stanford's "free" software. Quest Systems' software can be purchased by
calling them at (408) 496-1900. Neither I nor my employer have any affiliation
with Quest Systems. --- George
##############################################################################
From: ian@research.canon.oz.au (Ian Daniel)
Yeah, we have been in contact with Quest Systems re. their InterViews
product, which we may end up using. It is basically a Motif-appearance
InterViews, with some other extras such as shared library support.
However, we are still looking at the possibility of having a Motif
user interface created by a tool builder, and still using the structured
graphics functionality of InterViews. It would appear that users have
requested this, because InterViews 3.0, alpha release due out this week,
has been partitioned in such a manner in order to make this vaguely
possible.
I will include some mail messages on InterViews 3.0 after mine.
As a brief summary, they have made as separate libraries each of the
following:
- X-dependant code
- InterViews-look components, such as buttons and sliders
- low-level event handling
They have also included an InterViews user interface tool builder.
In summary, I recommend you get InterViews 3.0 when it comes out
(hopefully this week) and examine it, and the possibility of re-writing
the IV-look components and event handling so that it will work with
Motif. This is what we are looking at doing instead of throwing away
InterViews.
BTW, the Quest Systems product is based on InterViews 2.6, and a
source license, which we need because we have to port our product to
a proprietary machine, is not cheap. If InterViews 3.0 is not what I
am expecting, we may end up buying it though.
Ian
(mail messages follow ...)
From: Steen Linden <anubis@diku.dk>
Subject: Re: InterViews building tool query
In comp.windows.x you write:
>I have heard rumours of a public-domain InterViews building tool.
>Could someone provide me with some details of this please?
Here is the latest announcement from the InterViews mailing list. The
new InterViews release will be available by anonymous ftp from
interviews.stanford.edu. I think what you heard about is ibuild.
If you are interested in getting on the mailing list write to
interviews-request@interviews.stanford.edu.
Steen Linden (anubis@diku.dk) | It's all absolutely devastatingly true -
The Computer Department | except the bits that are lies.
DIKU, U. of Copenhagen | Douglas Adams:
Denmark | The Hitchhikers Guide to the Galaxy.
---8<---
From: linton@marktwain.rad.sgi.com (Mark Linton)
Subject: 3.0 status
Many people have been asking about 3.0, and I finally have started
to put together the release notes. Below is a partial description
of the differences between 2.6 and 3.0. Compatibility looks pretty good
so far--most applications have taken longer to convert to cfront 2.1
than to 3.0 (which isn't very long).
We are close to an alpha, a distribution that we will start using
ourselves day-to-day and will make available via anonymous ftp.
I'm also working on some documents for the X Consortium effort
that will start from InterViews.
Mark
Changes from Version 2.6 to Version 3.0
Overview
InterViews 3.0 supports very lightweight user interface
objects (called glyphs), contains the Unidraw library for
building graphical editors, an interface builder (ibuild),
and a simple WYSIWYG document editor (doc). We no longer
distribute g++, the GNU C++ compiler. InterViews should
build with any C++ compiler that accepts the 2.0 or 2.1 ver-
sions of the language.
The InterViews classes are now partitioned into six
libraries:
InterViews
Intrinsic user interface classes, including Glyph and
Interactor
IV-X11
X11-dependent implementation
IV-look
Classes with a concrete user interface, such as menus,
buttons, and scrollbars.
Dispatch
Low-level access to input events and IPC support.
Unidraw
Classes for building graphical editors, including sup-
port structured graphics, for graphical connectivity
(connector), dataflow (state variables), direct manipu-
lation (tools), and multiple views.
graphic
Structured graphics library with same functionality as
in 2.6.
The include files have been reorganized to match the
libraries; there are separate include directories Inter-
Views, IV-look, IV-X11, Dispatch, and Unidraw.
Configuration
We have simplified the writing of application
Imakefiles by defining macros that expand to the appropriate
definitions and understand the dependencies between
libraries. Use the macro ``Use_libInterViews()'' for a pro-
gram that uses the IV-look and base libraries (it will
automatically include libIV-X11, libDispatch, libXext,
libX11, and libm). Use the macro ``Use_libUnidraw()''
instead if the program uses the Unidraw library, or the
macro ``Use_libgraphic()'' instead if the program uses the
structured graphics library.
Coords
The Coord type is now a float. The default units are
printers points, not pixels. This change simplifies many
applications (such as document editors), that want to deal
with fonts, bitmaps, graphics, etc. in units useful for
printing as opposed to pixels. Applications compiled with
2.6 compatibility still define Coord as an integer.
Glyphs
Glyphs are the basic unit for building the presentation
side of a user interface. Glyphs define no storage by
default and are passed all contextual information for
display. The InterViews library defines three kinds of
glyph subclasses. Primitives are glyphs whose instances are
leaves, such as characters, labels, glue, and images. Com-
posite glyphs contain several components and typically
arrange them in some form. Glyphs that contain a single
component are called MonoGlyphs; they alter the component's
appearance or behavior.
Interactor is now a subclass of Glyph (actually of
Listener, the Glyph subclass that can express interest in
input). However, interactors are still allocated their own
X subwindows.
Windows
A window is an object that can be mapped onto a display
and receive input. Associated with a window is a glyph that
is the root of a hierarchy or acyclic graph. The window
draws the glyph to refresh the display and calls pick on the
glyph to determine what to do with input events. Two subc-
lasses of window are provided: ManagedWindow, for defining
information for a window manager, and PopupWindow for win-
dows that should be mapped outside of window manager con-
trol. Subclasses of ManagedWindow include ApplicationWin-
dow, TopLevelWindow, TransientWindow, and IconWindow.
Unidraw
The Unidraw library defines basic abstractions for
building graphical editors. Components represent the data
that the user is editing, commands are undo-able actions,
tools are direct manipulation objects for creating or chang-
ing components, and external representations store the
components in a domain-specific format. An important sub-
class of component is connector, which supports both graphi-
cal connectivity and dataflow among components. The Inter-
Views drawing editor (idraw) has been re-implemented using
Unidraw. The interface builder is also implemented with
Unidraw.
Dispatcher
Applications that only read user input need not be con-
cerned with the implementation of input dispatching. For
applications that need to integrate timeouts or IPC with
user input handling, however, the dispatcher is important.
There is one Dispatcher object per application.
Dispatcher::instance is a static member function that
retrieves this object. The dispatcher allows a file
descriptor to be associated with an IOHandler object whose
inputReady member function is called when input is available
from the file descriptor. For convenience, a generic
IOCallback(T) type is provided to define a simple IOHandler
as a pointer-to-member-function for an existing type T.
The Dispatch library also defines classes for perform-
ing RPC to other processes. The rpcstream class uses the
approach of the standard C++ iostream class, except the data
can be sent/received as binary. The rpcbuf class is a sub-
class of the standard streambuf and provides an interface
for opening and closing a stream (TCP) socket.
Interface builder (ibuild)
InterViews 3.0 contains ibuild, a tool for interac-
tively building a user interface. Ibuild allows the user to
arrange and connect common interactors and scenes, generate
the C++ code for the interface, compile the code and execute
the resulting mini-application. The generated code defines
a base class from which subclasses can be written to com-
plete the application. This approach allows the interface
to be modified later without affecting the subclasses.
Ibuild does not currently support glyphs.
Document editor (doc)
InterViews 3.0 contains a new application, doc, that is
a simple WYSIWYG document editor. Doc currently is the only
application that makes use of the glyph support in the
library, representing each character in a document as a
(shared) object. Doc uses a TeXCompositor object to compose
glyphs into a layout using the TeX formatting algorithm.
Doc reads and writes files using a LaTeX-like format, and
can also generate a PostScript file. Doc does not currently
have graphical editing capabilities, but can position and
display an idraw file as a figure in the document.
Class names
C++ class names are global. To avoid possible name
conflicts, the InterViews header files automatically define
class names to have the prefix ``iv''. This prefix is
defined in InterViews/iv.h and can easily be changed if
desired.
Compatibility
As much as possible, we have tried to make it easy for
applications based on InterViews 2.6 to work with this
release. To build a 2.6-based application with 3.0, use the
``Use_2_6()'' macro in the application Imakefile as well as
the ``Use_libInterViews()'', ``Use_libUnidraw'', or
``Use_libgraphic'' macros.
The InterViews configuration files have been rewritten
to eliminate unused parameters and rules and reorganize the
remaining parameters. Many parameters and make variables
were renamed for greater consistency and to avoid conflict-
ing with X11R4's parameters and make variables for C.
Experience has shown us that separate parameters and make
varaiables are necessary to support C++. Since users will
need to edit applications Imakefiles to use
``Use_libInterViews()'' and ``Use_2_6()'' macros instead of
LOCAL_LIBRARIES and/or SYSTEM_LIBRARIES anyway, we have also
replaced a few obsolete macros, rules, and make variables
with new ones. In particular, CompileInMachineDepSubdir and
InMachineDepSubdir have been replaced by the single macro
InObjectCodeDir, MachineMachineDepSubdir() and Depend-
MachineDepSubdir() have been replaced by the single rule
MakeInObjectCodeDir(), and MakeSubdirs(S) and
DependSubdirs(S) have been replaced by the single rule
MakeInSubdirs(S).
Some 2.6 features are not retained in 3.0. The event
types ChannelEvent and TimerEvent no longer exist. The
functionality can be achieved more easily and reliably using
the new Dispatcher class. The WorldView class also no
longer exists.
The IPC classes (Connection, ChiefDeputy, Deputy,
Packet, ObjectSpace, SpaceManager, ObjectStub, ObjectTag,
and ObjectTable) have been replaced by a smaller set of
classes with more functionality in the Dispatch library.
The old IPC classes were not particularly portable, did not
work properly across a network, and were hard to integrate
with the user interface side of an application.
The following Interactor window-oriented operations no
longer exist: Set/GetName, Set/GetGeometry,
Set/GetCanvasType, Set/GetInteractorType,
Set/GetGroupLeader, Set/GetTransientFor, Set/GetIconName,
Set/GetIconInteractor, Set/GetIconGeometry,
Set/GetIconBitmap, Set/GetIconMask, Set/GetStartIconic,
Iconify, and DeIconify. These operations have been super-
seded by operations defined on Window and ManagedWindow.
The canvas member of an interactor is now a Window.
Finally, the StringPool, StringTable, and Table classes
are no longer exported as part of the external interface to
the library. The reason for making them local to the
library implementation is that they may be replaced at a
future date and we do not want to support them as part of
the library interface.
Subject: Re: InterViews building tool query
From: John Vlissides <vlis@lurch.Stanford.EDU>
> I have heard rumours of a public-domain InterViews building tool.
> Could someone provide me with some details of this please?
A builder called "ibuild" is part of InterViews 3.0, the alpha for
which should be out this week. Here's an abstract that might help:
Current user interface builders are instance-based, meaning they use
instances of toolkit objects such as buttons and scroll bars to
represent the elements of an interface. These builders introduce
mechanisms that keep the toolkit instances passive as the designer
assembles the interface. This approach has at least two benefits: the
builder's objects look and feel exactly like the toolkit objects do,
since they are one in the same, and testing the final interface
involves simply disabling the mechanism that keeps the instances
passive during the building process. But the instance-based approach
has several disadvantages as well. To support passivation, the
builder must subvert normal toolkit semantics, which usually requires
low-level knowledge of and interaction with the toolkit. Moreover,
instance-based builders are only useful for building interfaces that
the underlying toolkit supports; supporting another toolkit requires a
new builder. Finally, it is difficult for such builders to support
features that are taken for granted in graphical editors for other
domains, features such as scrolling and zooming the interface, eliding
parts of it, and supporting multiple views.
Ibuild is an interface builder that lets a user manipulate simulations
of toolkit objects. Builder developers have avoided simulation-based
approaches because they offer no implementation advantage over an
instance-based approach when the builder is developed on top of a
traditional user interface toolkit. Ibuild, however, takes advantage
of Unidraw, a framework for building direct manipulation graphical
editors. Unidraw provides abstractions above the toolkit level that
simplify the construction of such applications. Unidraw makes a
simulation-based approach feasible, and it has enabled us to explore
the advantages of simulation as an alternative to instance-based
builders.
From: harald@itk.unit.no
Subject: Re: InterViews building tool query
Unidraw (current version "snapshot 0.4"), which is a "Framework for
building domain-specific graphical editors", contains a User Interface
Builder, ui. It operates (direct graphical manipulation) on *some*
InterViews objects and creates (InterViews) C++ code.
Unidraw is based on InterViews and available from Stanford (ftp).
(Installed *in* the InterViews tree.)
NB! InterViews 3.0 is coming soon. I guess Unidraw also comes in a
new and better version.
Regards, Harald Backer
SINTEF Automatic Control : Phone +47 7 594375
The Norwegian Institute of Technology : Fax +47 7 594399
N-7034 Trondheim : Email harald@itk.unit.no
NORWAY
--
----
George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu
Teknekron Communications Systems, Inc.| (415) 649-3752
2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.