grobicki@aplvax.jhuapl.edu (Thomas A. Grobicki) (12/07/89)
I've been working on some simple X programming using the book X WINDOW
APPLICATIONS PROGRAMMING by E.F. Johnson and K. Reichard (MIS Press). I've
gotten to chapter 2, test program 2 (main is below) and have found some
curious behaviour. If I don't include the sleep() call after the draw
commands but before the XFlush(), the lines and box do not appear in the
window. To add to the mystery the sleep() call must be at least 3 for a
Sun 3/60 running either MIT-X 11R3 or Sun OpenWindows or at least 1 for a
VaxStation 3100 running DECWindows. All the subroutines including the
draw commands are as simple as possible. The sleep() call can appear before
the draw commands and the program still works. Since the authors did not
include the sleep() call, I was wondering what might be happening. I added
them when I noticed that the program would work without the sleep() when
running dbx debugger using the step command.
Any help on this problem would be appreciated. I can send the remainder
of the program if this would help.
=================== Example Below ==============================
/*
** The test program. All this program does is pop up a window,
** draws 4 lines and a box in the middle, waits 15 seconds, then
** quits.
**
*/
/*
** Most every program that uses X will need to include
** Xlib.h -- which contains many definitions for X types
** and symbols.
*/
#ifdef VMS
#include <decw$include/Xlib.h>
#else /* UNIX */
#include <X11/Xlib.h>
#endif
extern Display *theDisplay;
main()
{
Window theWindow, openWindow();
GC theGC;
/*
** Set up our connection to X
*/
initX();
/*
** Get some info on the display and print it
*/
getXInfo();
/*
** Open a window
*/
theWindow = openWindow( 100, 100, /* -- x, y location */
300, 300, /* -- width, height */
0, /* -- This is NOT a pop-up */
&theGC ); /* -- Graphics Context */
/*
** Draw into the Window
*/
/* \ /
** ------
** | |
** | |
** ------
** / \
*/
drawLine( theWindow, theGC,
10, 10, /* Starting loction in x,y */
100, 100 ); /* Ending location in x,y */
drawLine( theWindow, theGC,
200, 100, 290, 10 );
drawLine( theWindow, theGC,
10,290,100,200 );
drawLine( theWindow, theGC,
290,290,200,200);
drawRectangle( theWindow, theGC,
100, 100, /* Starting location in x,y */
100, 100 ); /* width and height */
/*
** Send all output to the screen.
*/
/* Apparently returning from sleep() triggers the flush */
sleep(3); /* required for some reason */
XFlush( theDisplay );
/*
** Wait a while to be able to play with window.
*/
sleep( 15 );
/*
** Release X resources and connection
*/
XDestroyWindow( theDisplay, theWindow );
quitX();
}
/*
** end of file.
*/klee@chico.pa.dec.com (Ken Lee) (12/07/89)
In article <4262@aplcen.apl.jhu.edu>, grobicki@aplvax.jhuapl.edu (Thomas A. Grobicki) writes: > I've been working on some simple X programming using the book X WINDOW > APPLICATIONS PROGRAMMING by E.F. Johnson and K. Reichard (MIS Press). I've > gotten to chapter 2, test program 2 (main is below) and have found some > curious behaviour. If I don't include the sleep() call after the draw > commands but before the XFlush(), the lines and box do not appear in the > window. To add to the mystery the sleep() call must be at least 3 for a > Sun 3/60 running either MIT-X 11R3 or Sun OpenWindows or at least 1 for a > VaxStation 3100 running DECWindows. This is perhaps the most common user problem in X programming. I'll give the authors of this book the benefit of the doubt and assume they intended these programs to be read, but not executed. Your progam will not run on any system using a window manager (almost all systems). The window manager places new top level windows, sometimes with user positioning. Your problem is that (without the sleep) you are drawing on the window without waiting for this positioning to occur, thus the drawing drops in the bit bucket. Your server will tell you when you the window is ready by sending you an Expose event. You should always request Expose events on your drawing windows and always wait for them before drawing. This is mentioned in Section 1.1 of the MIT Xlib manual. Why does the window manager take 3 seconds under OpenWindows and only 1 second under DECwindows? You can figure that one out. :-) Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
erc@pai.UUCP (Eric Johnson) (12/08/89)
Our system, as it is wont to do, filled its root file system so I missed the original article. Sorry. In article <2241@bacchus.dec.com>, klee@chico.pa.dec.com (Ken Lee) writes: > In article <4262@aplcen.apl.jhu.edu>, grobicki@aplvax.jhuapl.edu (Thomas > A. Grobicki) writes: > > I've been working on some simple X programming using the book X WINDOW > > APPLICATIONS PROGRAMMING by E.F. Johnson and K. Reichard (MIS Press). I've > > gotten to chapter 2, test program 2 (main is below) and have found some > > curious behaviour. If I don't include the sleep() call after the draw > > commands but before the XFlush(), the lines and box do not appear in the > > window. To add to the mystery the sleep() call must be at least 3 for a > > Sun 3/60 running either MIT-X 11R3 or Sun OpenWindows or at least 1 for a > > VaxStation 3100 running DECWindows. > In my copy of the book, the sleep() is passed 10 seconds (pg. 63). > This is perhaps the most common user problem in X programming. I'll > give the authors of this book the benefit of the doubt and assume they > intended these programs to be read, but not executed. Actually, the program was intended to be executed, and seems to work fine on every system here. The programs are intended to be simple examples, in this case examples of line, rectangle and oval drawing, and NOT full X applications, however. The use of sleep() was to avoid describing events until later on in the book. > > ...The window manager places new top level windows, > sometimes with user positioning. Your problem is that (without the > sleep) you are drawing on the window without waiting for this > positioning to occur, thus the drawing drops in the bit bucket... Exactly. In chapter 1 (page 16), we describe the hints sent to the window manager. The default here is that we set override_redirect to True, to ask "the window manager to please leave the window alone. If it is set to False, the window manager can do what it wants to the window. Try the example program with the override_redirect field set to both True and False. When it is set to False, the window manager (if one is in use) may prompt the user to locate and size the window, using a mouse or other pointing device." (The sleep was set to 10 seconds in hopes this would be enough time for both methods :-) > ...Your server will tell you when you the window is ready by sending you an > Expose event. You should always request Expose events on your drawing > windows and always wait for them before drawing. This is mentioned in > Section 1.1 of the MIT Xlib manual... The rationale here was that we wanted to avoid explaining about Expose events (and events in general) until later on in the book (see chapters 5 and 6). We also wanted to give the user a chance to see how the window manager interacts (and get a chance to play with that interaction). Some other books on Xlib, if they provide example programs at all, seem to jump in far too quickly with the many complexities of X. Rather than hit the user with everything needed for a full application in chapter 1, we wanted to go a little slower, to ease the task of learning X. The idea was to divide the complexities of X/Xlib into more digestable bites, such as drawing (output) functions, colour, text and events. We try to slowly build up code and add on to the knowledge gained in previous chapters. None of the example programs in the first part are intended to be fully fleshed-out applications. Instead, we tried to focus on a narrow subject matter for each chapter, and provide programs that show how various aspects of X work. I'll certainly take the blame for this, as much of this approach was developed from my experiences learning X10 (on an old HP 9000/320). In learning X10, I wished for: 1) Rather than mere descriptions of each function (very useful as a REFERENCE, but not so handy as a tutorial), I hoped for descriptions of how the functions worked together. 2) Example programs, showing how the functions fit together, which I think are invaluable. 3) Documentation that I could read once and be sure I understood it. 4) Clear separation between Xlib and proprietary toolkits. (This was the straw that broke my back with the X10 documentation that was available to me.) In trying to learn a new graphics system (including Hp1000s, VAX-VMS/GKS, HP200s, PCs, Macintoshes, SunView, X10, X11, etc.), I find that tutorial material really helps when learning the first basic concepts. With colour, for example, I find that if I can learn how to draw a line in red, the rest of the colour model(s) come much easier. (The effort required to learn how to draw a line in red--a very simple task really-- from the documentation available with the X11R3 sources was one of the motivating factors for Kevin and I to write X Window Applications Programming.) Once I've picked up the basic concepts, I frequently turn to reference material to flesh out my knowledge and solve whatever problem/task is on the agenda for that day. Thus, we didn't find the need to cover every single Xlib function in a beginner's tutorial on Xlib. Instead, we focused on the functions that we considered most important from a user perspective. The functions we chose are a superset of the functions used in real live application programs. (I don't speak for Kevin, but the majority of X11 work I've done is for industrial automation systems for my employer--Boulware Technologies.) Once the basic concepts are mastered, I suspect most people will head for reference books, until they need to figure out a new concept, when a tutorial is handy again. Of course, whether you agree with this approach or not is a matter of opinion. Others seem to have used different approaches, and I'd like to note that I'm emphatically NOT trying to put anyone else down. Due to the long lead time in book publishing, we only saw, for example, the excellent Jones book as we were putting together the appendices. > > Why does the window manager take 3 seconds under OpenWindows and only 1 > second under DECwindows? You can figure that one out. :-) > > Ken Lee > DEC Western Software Laboratory, Palo Alto, Calif. > Internet: klee@decwrl.dec.com > uucp: uunet!decwrl!klee If you have any questions on X Window Applications Programming, please send me email to the address below. Unfortunately, our connection to Usenet is tenuous at best. Please also include a "bang"-style return address--they seem to work better. Disclaimer: I speak only for myself, not my employer. -Eric -- Eric F. Johnson, Boulware Technologies, Inc. 415 W. Travelers Trail, Burnsville, MN 55337 USA. Phone: +1 612-894-0313. erc@pai.mn.org - or - bungia!pai!erc (We have a very dumb mailer, so please send a bang-!-style return address.)