Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ames!xanth!mcnc!ece-csc!ncsuvx!cscadm!mauney From: mauney@cscadm.ncsu.edu (Jon Mauney) Newsgroups: comp.windows.x Subject: Re: Simple programming quiz Message-ID: <3184@ncsuvx.ncsu.edu> Date: 15 Jun 89 17:47:10 GMT References: <29675@ucbvax.BERKELEY.EDU> Sender: news@ncsuvx.ncsu.edu Reply-To: mauney@cscadm.UUCP (Jon Mauney) Organization: Computer Science Faculty, NCSU, Raleigh NC Lines: 56 In article dana@dino.bellcore.com (Dana A. Chee) writes: >In article <29675@ucbvax.BERKELEY.EDU> elf@gilan.Berkeley.EDU (Marc Singer) writes: >> >> Why does this apparently simple X program not work? >> ... >> XMapWindow(display, xwnd); >> XFlush(display); >> XDrawString(display, xwnd, gc, 10, 10, szLabel, strlen(szLabel)); > >The great "Drawing in an unmapped window" error strikes again. > I would like to use this example as a springboard from which to jump onto a soapbox and talk about the nature of Xlib programming. The highly asynchronous nature of X takes quite a bit of getting used to. Therefore, those people who write about X need to be careful to explain what is going on. The "unmapped window" bug is a prime example. I have two books on Xlib programming, "X Window System" by Scheifler-Gettys-Newman, and "Introduction to the Window X System" by Jones. In neither book does the discussion of XMapWindow even hint at this pitfall. Even Dana Chee's explanation is subject to quibbling. The Scheifler book -- which I take as official, whether it is not -- says on p44 "A window is considered mapped if an XMapWindow call has been made on it" (subject to various exceptions listed in subsequent paragraphs.) Therefore the bug must be that the window is mapped but not exposed. It seems reasonable that the X server will process requests in the order that they are issued by the client. Therefore it seems reasonable that if I create a window, set its gc and attributes, and then call XMapRaised followed by XFlush, then the window exists and is mapped, and any subsequent draw requests should work. If the server needs extra time to finish mapping the window, well fine. I issued my requests in the proper order so I expect the server to service them in the proper order. Obviously, this is not actually the case. I'm certain the Consortium knows a good reason why it isn't the case. I'm damn sure they aren't going to change things at this point in the game. But the Consortium needs to make sure that the protocol definition is unambiguous about such behavior, and writers of tutorials need to make such distinctions blatantly obvious to the novice. Obviously, all useful programs must have a loop that accepts expose events, since a window may be obscured in many ways. But there are many reasons to want to write code that goes for quite a while before looking at events, and during program development this is especially true. Jon Mauney Computer Science Dept, NCSU mauney@cscadm.ncsu.edu