"Michael_K._Powers.WBST139"@XEROX.COM (09/25/87)
Are any of the developers of this package on this dl? I have some questions and curiosities that I would like to discuss, If you have a moment. Mike Powers powers.wbst139@Xerox
c287-ab@cory.Berkeley.EDU (Class Account) (10/16/87)
There is a graphic editor call idraw released with the interface . Any one out there succeeded in making it work please reply to me . I desperately need a graphic editor that works in X window environment and it seems this is the one. I have the whole code for InterViews sitting here but no success in firing it up . The interface is in C++ some of the applications in Modula-2 . gamal@cevax.berkeley.edu
grunwald@uiucdcsm.cs.uiuc.edu (10/18/87)
I was wondering about the InterViews stuff myself -- it would be very useful to me, but the fact that idraw is in modula-2 means I can't compile it on our Sun. Along the same lines: has anyone hacked out a C++ compatibility package for X11 yet (i.e. make Displays, Windows, etc be classes, and have their functions be members)
vlis@Shasta.STANFORD.EDU (John Vlissides) (10/20/87)
Please send inquiries/problems concerning InterViews 2.0 to linton@lurch.stanford.edu. John Vlissides Center for Integrated Systems, Stanford University
calder@Shasta.STANFORD.EDU (Paul Calder) (03/19/88)
In article <7712@agate.BERKELEY.EDU> rusty@velveeta.berkeley.edu () writes: >Widget placement; needs something like TeX "glue". For example, I am >making a dialog box that consists of a label widget with the string >"really quit?" and under it 2 buttons "yes" and "no". I want the yes >button flush left and the no button flush right. I couldn't get this >layout. I would like to be able to put a spring or some "glue" that >has infinite expandability between the 2 buttons. > > rusty c. wright > rusty@cartan.berkeley.edu ucbvax!cartan!rusty Check out the InterViews toolkit on the X11 distribution tape. It provides EXACTLY the sort of composition you mention, and a whole lot more besides. Briefly, InterViews is an object-oriented user interface toolkit written in C++. It runs on either X10 or X11, and on MicroVAX or Sun 3 workstations. If you don't have the X11R2 tape, you can get InterViews by - 1. anonymous ftp from lurch.stanford.edu 2. sending a "stamped, self-addressed tape" to Prof. Mark Linton Center for Integrated Systems, Room 213 Stanford University Stanford, CA 94305 Paul Calder Computer Systems Lab CIS 019, Stanford University, CA 94305 calder@uluru.stanford.edu
annala@neuro.usc.edu (A J Annala) (05/15/89)
What exactly is InterViews ... can it be compiled with gnu C++ compiler? Thanks, AJ
jsilarry@cpsc.ucalgary.ca (Larry Mellon) (08/04/89)
I'm trying to locate more information on a product called 'Interviews'; apparently a C++ interface to Xwindows. Could someone please send me the address and/or phone number for the producers of Interviews? Larry Mellon <jsilarry@cpsc.ucalgary.ca> Jade Simulations International (403) 282-5711
gangal@cpsin3.cps.msu.edu (Gangal Sameer H) (03/06/90)
I am using interviews and have some problem making a part of my
code work.
As a matter of fact I am having problems with updating a object called
View which is derived from GraphicBlock. I capture an event
and try to append a graphic(rectangle) to the picture( which was
passed to the constructor of View) and then call Update on the view.
It gives me an error at Update.
I even tried a simple program to insert a rectangle into a View( inherited
from GraphicBlock)
class Minidraw;
class View:public GraphicBlock{
public:
View(Rect*);
};
class Minidraw:public MonoScene{
public:
Minidraw();
Interactor * Interior(View *);
};
Minidraw::Minidraw()
{
Rect * rect = new Rect(0,0,10,10);
rect->SetColors(pblack, pwhite);
rect->SetBrush(psingle);
rect->SetPattern(psolid);
rect->FillBg(true);
View * view = new View(rect);
Insert(new Frame(Interior(view)));
}
View::View(Rect * r):(nil, r)
{
input = new Sensor(updownEvents);
shape->width = round(20*cm);
shape->height = round(10*cm);
}
Interactor * Minidraw::Interior(View *v)
{
return new HBox(v);
}
main( int argc, char **argv){
World* world = new World("minidraw", argc, argv);
world->Insert(new Minidraw);
world->Run();
}
this program gave me a CORE dump when the constructor for
the View was called.
Any kind of help will appreciated very much.mbartucc@Teknowledge.COM (Michael Bartucca) (04/13/90)
Does anyone know if InterViews can be used with X11R3 and AT&T C++ 2.0? I already know that InterViews 2.6 can be used with X11R4 and AT&T C++ 2.0. Please respond to mbartucc@Teknowledge.Com or (415) 424-0500 X439 Thanks. Mike Bartucca Cimflex Teknowledge, Palo Alto, CA
rick@cstr.ed.ac.uk (Rick Innis) (09/06/90)
Compiling InterViews, I got the following message while making idraw:
errhandler.o: Undefined symbol set_new_handler() referenced from text segment
errhandler.o: Undefined symbol set_new_handler() referenced from text segment
*** Error code 1
make: Warning: Target `all' not remade because of errors
Current working directory /home1/src/X.V11R4/iv/src/bin/idraw/SUN4
A quick grep of the sources produces the following:
rick(brodie):1218% egrep set_new_handler *.c
errhandler.c:extern NewHandler* set_new_handler(NewHandler*);
errhandler.c: set_new_handler(oldnew);
errhandler.c: oldnew = set_new_handler(&out_of_memory);
rick(brodie):1219%
set_new_handler doesn't seem to be defined anywhere; a grep for 'handler'
doesn't turn up anything helpful either. Anyone got any useful suggestions?
Email and I'll summarize if anyone else wants to know.
--Rick.rick@cstr.ed.ac.uk (Rick Innis) (09/07/90)
Could the person who mailed me a reply to my message about idraw compilation errors please reply again? My mailer bombed out on me and trashed your message. (Apologies to the rest of the net for the use of bandwidth.) --Rick.
noren@dinl.uucp (Charles Noren) (09/08/90)
Sorry to waste the bandwidth, but my e-mail keeps bouncing.
Thanks Ciaran McHale (cjmchale@cs.tcd.ie or
cjmchale%cs.tcd.ie@cunyvm.cuny.edu), your mail (old-fashioned real
mail, no less) on your personal experiences and insights into
InterViews was great! It was just the information I needed
(you should consider posting it)!
Thanks again,
--
Chuck Noren
NET: dinl!noren@ncar.ucar.edu
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930cjmchale@swift.cs.tcd.ie (09/10/90)
In article <1726@dinl.mmc.UUCP>, Chuck Noren thanks me for info I sent him regarding my opinions on InterViews. > your mail (old-fashioned real mail, no less) on your personal > experiences and insights into InterViews was great! It was just > the information I needed (you should consider posting it)! I had `old-fashioned real mail'ed him since my email kept bouncing. As Chuck indicates, maybe other people will find the email of use so I'm posting it here. Please note that the opinions expressed are definitely my own and may be considered by some to be of an extremely religious nature (which is why I didn't post them originally). If anybody wants to flame me for my opinions the please do so via email and I will summarise (comp.windows.x has enough traffic without yet another flame war generating countless postings). %%%%%%%%%%%%%%%% start of my email response to Chuck %%%%%%%%%%%%%%%% In article <1681@dinl.mmc.UUCP> you write: >Here is the situation: > >1. We will be using a commercial C++ compiler. >2. We are redoing a graphical user interface using X-Windows > as the foundation. The user interface will have: > a. Buttons > b. Simple menus (walking menus would be nice, but Xt does > not support it nicely yet and neither does InterViews > as far as I can tell). Menus include pop-up and > persistent. > c. Scalable-size graphical objects, that are a composite > of circles, rectangles, polygons. These can be filled > or unfilled. > d. Geographical maps of various sorts. > e. Displays can be constructed by the user using scalable-sized > objects and maps. > f. Displays organized into hierarchies. > g. Certain information displayed as bar-charts, line-graphs, > pie-charts, with lines of different types (color, thickness, > dashed/dotted/unbroken). > h. Scrollable text and graphics windows. > >The question: > >What inexpensive/public domain toolkit best suits the job. Any toolkit (Xt based such as Athena or Motif etc, XView, InterViews ...) will be able to give you the normal set of buttons, scrollbars, textwidgets, popups etc. They may look different from one toolkit to the next but they'll be there. That's about half your requirements met so far. The only thing then is: What toolkit provides "good" graphics? I'll come back to this point later in this email. >We have been getting up to speed on Xt of X11R4 and know how >to do everything we want using Xt. Good. Stick with Xt then. Several reasons why include: o X is a windowing system. So is the windowing system on the Macintosh. So is Windows (or whatever it is called) on the PC. Question: What have all these windowing systems got in common? Answer: they are all different. The punchline is coming up now. What is "InterViews"? Answer: It is a windowing system. Remember: X is a window system; InterViews is a window system; they are *different* window systems. Saying that InterViews is a X toolkit is misleading. Yes, it does happen to be built on top of X but it is actually a windowing system. Think of InterViews as being a window system which just so happens to be built on top of Xlib. It might have been built on top of bare hardware but for prototyping it was first developed on top of Xlib. (The last sentence is actually a bit misleading but I think it gets the message across. As far as I know, one of the main aims of InterViews is to provide a system which is portable across different window systems such as X, the Macintosh windowing system, that on the PC etc. I don't know if InterViews has been implemented on top of anything besides X yet but it may be in the future.) The InterViews windowing system is *different* from X. So most of what you have learnt about X can be thrown away if you use InterViews. InterViews uses terminology which is different from that used in Xlib and Xt. This leads to confusion until you look at the source code and realise that an Interactor is basically the same thing as a widget (i.e. a window with some semantics attached), and a "world" is basically the "Display *". A "PropertySheet" is basically the X resource manager and on and on and on. I'm still not sure what the InterViews equivalent for a GC is. o There *are* good tutorial books available which tell you how to program using Xlib and Xt. There is also comp.windows.x where you can look to for help. (Most people who read comp.windows.x know either Xlib, Xt or both.) On the other hand, the *only* documentation I know of for InterViews is the source code and the manual pages. I don't know of any books which you can buy if (sorry, "if" should read "when") you get stuck. [ Disclaimer: I used InterViews last year. I don't know if the current release (on the X11R4 tape) has better documentation. ] o A plus in InterViews favour is that being C++ based, it is easy to work in an object-oriented manner with windows (widgets/Interactors) and graphics. Xt is object-oriented based but is written in C so you have to follow "conventions" to achieve the benefits of OO design. These Xt "conventions" would become syntax and compiler checks if Xt was written in an OO language such as C++. However, a remarkably good free tool has become available for developing the look and feel of an Xt based application. This takes most of the repetitiveness out of using Xt. This tool is called the Widget Creation Library (WCL). Most applications can be split into two logical parts: 1. Create all the window for the application during initialisation. (The "look and feel" of the application.) 2. Write all the "callbacks" (Xt termionology). (What the application does when the user presses a particular button etc.) One advantage of using InterViews is that step (1) is simpler than using Xt. However, WCL makes step (1) even easier and allows for some staggering productivity gains. Hence, by using WCL Xt is still ahead of InterViews for creating the window hierarchy of an application. Ok. Now for graphics support. I know that the Athena widget set (Xt based) doesn't provide any graphics support; the programmer uses what is available at the Xlib level. I would imagine that several other toolkits take this aproach but since I have only used Xlib, Athena and InterViews I can not say for definite. InterViews does supply C++ graphical objects Thus you have have line/circle/polygon etc objects. Unfortunately, since InterViews is *different* from X, so too are the graphics it provides. They are not simply object wrappers around the Xlib functions. InterViews provides you with a different graphical model than that available at the Xlib level. And InterViews does a good ("good" in a sarcastic sence) job of hiding Xlib from the programmer so if you can't do what you want with the InterViews graphical model you may not be able to escape down to Xlib to do it. (That's the way it was when I was using InterViews. I lamented this to Mark Linton and I think that it *might* (i.e. check) now be easier to access Xlib if you need to.) I'll give some background info on the projects we developed with InterViews. Last year the research group that I'm in wanted to put together some graphical demonstrations to impress the reviewers who decide how much funding we get. The more impressed they are ... :-) Our group is developing a distributed, object-oriented, persistant (insert a few more buzz words) operating system and language so to show this off to best effect we wanted the following demos: o Air Traffic Control (ATC) simulation: There are a dozen or more ATC regions in Europe so this is a naturally distributed application. We wanted to have a process for each ATC region. Each process would communicate with its neighbouring ATCs and a graphical display of airplanes flying all of Europe would appear via a front end X application. [ By the way, if you think you might need to have an X application acting as a front end for a back end process then ask me to send you some email I've saved about how to make an X client "multiplex" between the X server and a socket/pipe connection. ] o Travelling Salesman (TS). We wanted to show some speedup when several processes tackled this problem concurrently. The front end graphical display shows every 100th (or whatever) attempted solution so the user can see progress being made. o A browser to show off transparency and fault tolerance. Hitting a few buttons would fetch data from across a network. The ATC and TS showed a map of europe with lots of objects moving over it. In the ATC it was airplanes flying. In the TS lines were drawn from one city to the next showing the route taken. I worked on the ATC graphical front end so I'll describe that. InterViews' graphical model turned out to be initially brilliant (i.e. we could prototype fast) for what we wanted but some limitations (and being stuck with them by not being able to get down to Xlib) caused me to curse quite a lot and miss some sleep. I'll explain: InterViews provides a base class "graphic" from which line, circle, polygon etc are derived. There is also a graphic list (actually called a "Picture") which can be used to compose composite graphics. For the ATC, the map of Europe consisted of land masses (filled polygons) upon which we drew airports, VORs (Very high frequency Omni directional Ranges or something like that; basically they are to airplanes what lighthouses are to ships), the names of airports and "air corridors" (the "roads" that airplanes fly along). The symbol for an airport is a cirlce with some small filled circles around its circumference. So we could derive an "airport" class which contained these in a "Picture". Similarly, a VOR is composed of two circles and a triangle. So far so good. Airplanes are to fly over the map of Europe; We had an "airplane" class which drew a filled polygon for this. InterViews provides a "GraphicsBlock" interactor (window) which you associate with a graphic. When the GraphicsBlock window gets an expose event it will redraw what is necessary. You can scroll around (as can be done easily in Xlib) and zoom in/out (no Xlib support for this) which is very handy. But that's where we had the problems... We wanted to place an upper limit on the magnification of the airports, vors and airplanes. Initially the map of Europe is drawn so that it all fits onto the screen. At this scale Ireland is about 70 pixels long. The airports, vors and airplanes are drawn well out of proportion to the land masses so that they are visible. As the user zooms in everything is magnified. But if he continues to zoom in then the airports, vors and airplanes were not to be magnified beyond some upper threshold. This was *extremely* difficult to do. Similarly, we didn't want the names of the airports to be magnified at all. (InterViews "magnifies" text by drawing a filled rectangle for each pixel of the original text thus giving a disgusting chunky banner effect.) This also required a nasty hack. Another problem we had with the graphics was the speed of update. If I had access to Xlib I'd have drawn the map to a pixmap. When an airplane moved on the map I'd use XCopyArea() to redraw the map from the pixmap to the window and then redraw the airplane. The only time to redraw the map to the pixmap would be when it was scrolled or zoomed in/out. I know *now* that this is possible but at the time I couldn't figure out how to do it due to InterViews woeful documentation. What InterViews did was to redraw the land masses, airports, air corridors and vors affected when an airplane moved. The screen would flash very noticeably and, because the map was pretty complex, would take over a second to redraw itself. I felt very frustrated with this since I knew that I could do it much better at the Xlib level. We had similar problems with the TS demo. Ideally we would have drawn the map (land masses, a circle and the name for each city) to a pixmap and refreshed the screen quickly with this. The attempted route was drawn with lines. They were drawn quick enough but redrawing the map before drawing the next route was embarrasingly slow. (Writing 200+ text names for the cities is very slow.) What I think is ideally needed is a graphics library which has the following features: 1. It allows scrolling. This is trivial. 2. It allows zooming in/out. VERY USEFUL. 3. It doesn't hide Xlib from the programmer. 4. It is written in C++ (or your favourite OO language) so that there will be an object wrapper around the Xlib graphic primitives. (3) is where the InterViews graphical model is deficient. If a graphics library has (3) then it could be used with any toolkit/widget set that allows access to Xlib. This includes XView, Motif and the Athena widget set. (These three just so happen to be three of the more popular toolkits around so this is an important point.) It would also require a minimum learning curve since if you're familiar with Xlib it would be easy to get to grips with the graphical toolkit. I think that such a toolkit would be so useful in fact that I'm writing one in my spare time. (Maybe if it turns out pretty good then it might become part of X11 R5 contrib and I might be famous :-). At the moment its 5000 lines of C++ source (100+ Kbytes). Most of the source is not for the actual graphic objects but for the infrastructure they need such as a GC cache and something equivalent to InterViews' GraphicBlock. I would estimate that there is another man month or two left to polish it off to my padantic standards (but since I'm only doing it in my spare time it will take a bit longer). If you hear about any other graphical toolkit that fits the requirements mentioned above then please let me know about it. (I think that using it for the graphics and WCL for the widget hierarchy would make for an excellent development environment.) If you don't hear about any other graphical toolkit then you can either hope for the best with InterViews or write your own. If you want to develop your own then I'll gladly send you mine along with a big README type file to describe how I've approached it. You might like to look at it to see how much work is involved and what design decisions to make etc. (If/when I finish my graphics library I intend to make it available free to whoever wants it; so don't worry about there being any copyright/left restrictions on it if you want me to send it to you.) >Some related questions: > >1. How widely used is InterViews? >2. How strongly does Stanford support (or whatever the real > development entity is) InterViews development? > As X-Windows matures, will InterViews mature? >3. How much of a standard is InterViews now and how > likely will InterViews be a standard in the future? >4. How mature is InterViews? How bug free is it? > How compatable is it to other libraries (I've heard > of an incompatability with NIHCL)? Sorry, I don't know the answers to those questions. In case you've never heard about WCL, here's part of one of the READMEs that come with it. The .signature at the end of it is of the guy who is responsible for it in case you want to ask him to email it to you or tell you where you can ftp it from. ------------ CUT HERE ----------------- Widget Creation Library, Motif Resource Interpreter, Athena Resource Interpreter: An Easier Way to Develop Applications using Motif and Athena Widgets. Window-based applications are notoriously difficult to program. When the Macintosh was introduced in early 1984, Bill Gates projected that 50% of Microsoft revenues would come from Mac application by October 1984. In reality, the first Mac applications were only beginning to be shipped by that date. When Steve Jobs left Apple and developed the NeXT computer, the window environment was specifically designed to support a WYSIWYG interface builder. NextStep and the NeXT IB were the results of this effort. The X developers at MIT and DEC also needed an easy way to develop windowed applications. Instead of developing a WYSIWYG tool like NeXT, they developed a toolkit where interfaces were specified using C code, and could be significantly modified via `resource files' using a minimum number of attribute specifications. They provided an instance attribute inheritance mechanism to propogate attributes throughout an interface. This allows such simple specification as the following to alter every font in an interface: *font: 9x15 The toolkit is called the Xt Intrinsics. The windows, buttons, menus, scrollbars, etc., are called Widgets. The Athena Widgets are one set of user interface objects built upon the Xt Intrinsics. Motif is another set of widgets. As time went on, developers of widget-based applications found the resource files to be more and more useful. For the fourth release of the X11 window system, many of the example programs evolved to the point that only the raw behavior of the applications were specified in C, with most of the look and feel being specified using resource files. At the fourth annual X Technical Conference, several people pointed out that resource files could be used to specify everything about a widget based user interface, except the actual "tree" of widgets, their types, and bindings of behaviors to the user interface widgets. Could the resource mechanism be enhanced to allow these to be specified as well? Martin Brunecky at Auto-Trol in Denver Colorado took up the challenge, and posted a simple set of routines which he called WsXc, for "Window System: Xrm Creation." Xrm stands for X Resource Manager, which is a heirarchical database for keeping arbitrary named data related to X window interfaces. The Xt Intrinsics use Xrm for widget resources. The basic idea of WsXc is to search the Xrm database, starting at the root, and pull out resources which describe the widget heirarchy and bindings to callback functions. Over the next several months, WsXc was repackaged as Mri (Motif Resource Interpreter), and then Ari (Athena Resource Interpreter), and finally generalized into the Widget Creation Library. The result provides several significant benefits to the developer and the user: o Rapid Prototyping: Arbitrarily complex widget interfaces may be specified, and many common behaviors (pop-up, change attributes, exit) can be specified for the interface. o Prototyping Environment is the Development Environment is the Delivery Environment: There is no specific breaking point between prototyping, developing, and tuning a delivered program. o Minimum Specifications: The Xrm and Xt Intrinsics instance attribute inheritance mechanism is fully utilized, so a minimum number of specifications can describe a complete user interface. o Extensible: Adding new widget types and callback routines is trivial. o Widget Set Independent: The C code which provides the behavior of the application can frequently be written in a widget set independent manner. This allows an application to be written which supports multiple look-and-feel definitions: Motif, OpenLook, and Athena interfaces can all be front-ends to the same underlying application. o The user can make any change to the interface: Deeply nested menus can be substituted for dialog boxes, or vice versa. Any label or image can be altered, which supports inter- nationalization. The Widget Creation Library Distribution ---------------------------------------- The distribution is available in several ways. The preferred approach it for you to get the compressed tar file using anonymous ftp from either of these ftp servers: devvax.jpl.nasa.gov (128.149.1.143) pub/Wc1_03.tar.Z expo.lcs.mit.edu (18.30.0.212) contrib/Wc1_03.tar.Z If you have never used ftp, this is how it is done: # ftp devvax.jpl.nasa.gov Name: anonymous Password: <anything non-null> ftp> binary ftp> cd pub ftp> get Wc1_03.tar.Z ftp> quit # uncompress Wc1_03.tar.Z # tar xvf Wc1_03.tar If you do not have ftp, I will can you the 9 shar files through email. Also, I can send the compressed tar file uuencoded. This is the least reliable way, since the uuencoded file is 246547 bytes long, which will cause some mailers to barf. If you really don't know if you want the whole distribution, I can send you a shar file which contains just the README files. If you send me mail asking for the shar files, the uuencoded file, or the README shar file, my mail back to you may bounce. If you don't hear anything for a couple of days, try again... The distribution includes the following README files: 0thREADME Fixes and enhancements to this version 1stREADME Intro, credits, and build instructions 2ndREADME Minimimum information to use Wc from an application 3rdREADME Wc Resources 4thREADME Standard Callbacks 5thREADME Standard Actions 6thREADME Wc Widget Creation, Widget Registration, Callback Registration, and Action Registration Functions 7thREADME Writing Callback Functions ------------------------------------------------------------------------- David Smyth david@jpl-devvax.jpl.nasa.gov Senior Software Engineer, seismo!cit-vax!jpl-devvax!david X and Object Guru. (818)393-0983 Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109 ------------------------------------------------------------------------- ------------ CUT HERE ----------------- I know that you have to consider factors such as "how much support is there for WCL?" and so on. There's probably no guaranteed support (check) but I don't think that's a big risk. If you get it and mess around with it for a day or two I think you'll realise (as I did): 1 Wow! This looks extremely promicing. (Within two or three hours). But there's got to be a catch. It must have a limitation in <such-an-area>. 2 Great! I can do that after all. (After modifying an example program to convince yourself that you do have complete control.) 3 Oh, so that's what the grip/box/dialog/whatever widget does. (After ten minutes of messing around with an example program and changing a few resources to see what happens.) 4 "But officer, I didn't mean any harm..." (After being arrested for drunk and disorderly conduct that night when you celebrate having found such a wonderful productivity tool that really does live up to its claims. :-) Thankfully, (4) didn't happen to me. (1), (2) and (3) did. (3) alone is worth a lot. (Think about it and you'll realise that it is.) You also have a fallback guarantee with WCL. WCL allows you to create your application's widget hierarchy very quickly. In the unlikely event that you discover a fatal bug in WCL then all you need to do is manually convert the WCL description of the widget hierarchy into C code. This is (labourious but) trivial to do as you'll discover for yourself if you try out WCL for a day or two. So, if WCL fails at the 11th hour you *can* escape back to raw Xt. In case I haven't mentioned it before---WCL is free, as are InterViews and the Athena widget set, A few other random notes that might be of interest to you. 1. Don't be put off by the fact that the Athena widget set does not have a widget which you can use for drawing graphics. At the end of the Athena widget set manual there is a section on how to write your own widget and the example given is such a widget. But rather than spend a day or so reading that section and writing your own you have two other choices: (a): Use a coreWidget and use XtAddEventHandler() to register whatever callbacks you require. An Expose handler is one that comes to mind. Also, perhaps a callback for button press etc. (b): Use a suitable widget that somebody else has written. A good "DrawingArea" widget with callbacks for Expose, Button/Key/Press/Release, Resize and MotionNotify events was distributed with version 2 of an X demo program called "xball". If you don't alreadt have this program then I can email it (or just the DrawingArea widget, if you prefer) to you. 2. If you haven't already done so, get a copy of the "frequently asked questions" and "X bibliography" postings which are posted to comp.windows.x about once a month. If you need some good books on "X progarmming made easy" then I'd suggest the one written by Oliver Jones (for Xlib) and lots of people on the net have recommended the one by Doug Young (for Xt programming). >-- >Chuck Noren >NET: dinl!noren@ncar.ucar.edu >US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260, > Denver, CO 80201-1260 >Phone: (303) 971-7930 Get back to me if you're unclear about anything. In case you're wondering who I am: I'm speaking only for myself etc. I am 22 and am doing research in synchronisation mechanisms for my masters degree. My exposure to X started last summer when I was told to "learn X" for the demonstration programs we had to write. I fell in love with it and have been hacking with it ever since. I have no experience with any form of management responsibility so I do not know what you, as a project leader, consider to be important criteria for choosing an X toolkit. The above opinions are based on my experiences with Xlib, Xt, WCL, InterViews and what I have gleamed from comp.windows.x. Regards, Ciaran. ------- Ciaran McHale Department of Computer Science, Trinity College, Dublin 2, Ireland. Telephone: +353-1-772941 ext 1538 FAX: +353-1-772204 Telex: 93782 TCD EI email: cjmchale@cs.tcd.ie or cjmchale%cs.tcd.ie@cunyvm.cuny.edu %%%%%%%%%%%%%%%% end of my email response to Chuck %%%%%%%%%%%%%%%% Once again, the opinions are _mine_ and if you want to flame then please do so by email. Ciaran. "Flatulence brings out the worst in me" -- Ciaran McHale Department of Computer Science, Trinity College, Dublin 2, Ireland. Telephone: +353-1-772941 ext 1538 FAX: +353-1-772204 Telex: 93782 TCD EI email: cjmchale@cs.tcd.ie or cjmchale%cs.tcd.ie@cunyvm.cuny.edu My opinions are mine but you can share them too if you want.
song@minster.york.ac.uk (01/07/91)
I just start to use InterView to prgram. Could anyone give me some suggestions on the following issues: Is there any InterView prgrammer guide available ? Is there any InterView debug tool available ? Is there any C++ dbx tool available ? Thanks,
fischer@iesd.auc.dk (Lars P. Fischer) (01/08/91)
>>>>> On 7 Jan 91 11:41:55 GMT, song@minster.york.ac.uk said:
song> Is there any C++ dbx tool available ?
gdb, for g++ (GNU C++).
/Lars
--
Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one
CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.