xug@lta.com (X User's Group) (04/03/91)
[Last changed: 02 Apr 91] This article contains the last of four parts of a set of answers to some Frequently Asked Questions (FAQ) often seen in comp.windows.x. It is posted to help reduce volume in this newsgroup and to provide hard-to-find information of general interest. Please redistribute this article! ---------------------------------------------------------------------- Subject: 88)+ Why can't I link to the Xlib shape routines? When I try to compile certain programs, I get the following link error: Undefined: _XShapeQueryExtension _XShapeCombineMask These routines are actually part of the Shape Extension to X (SHAPE) which was introduced in the MIT X11R4 distribution and allows non-rectangular windows. Like the other sample server extensions, the shape extension will only run on a server which supports it. Pre-X11R4 servers, as well as many vendor-supplied servers, do not support the shape extension, in which case they will display rectangular windows anyway. In order to use the shape extension, you must link to the library libXext.a. In the X11R4 distribution, this library and the associated includes will be in the mit/extensions directory. If you do not have these files, do not despair: many freeware programs which use the shape extension can also be compiled without it by removing the -DSHAPE define from the Makefile; you can probably do this and compile successfully against your older vendor-supplied X libraries. [from John B. Melby, melby%yk.fujitsu.co.jp@uunet.uu.net, 3/91] ---------------------------------------------------------------------- Subject: 89)* What are these problems with "_XtInherit not found" on the Sun? When I run a X program that I wrote on a SunOS 4.0.3 or 4.1 machine I get the error "ld.so: symbol not found _XtInherit". What you are seeing is a side-effect of a kludge in the R4 libXt.a to get Sun shared libraries working. Apparently, you can't share a function that is both called and compared, as _XtInherit is. This was handled by putting _XtInherit in the same file as a function that is always used, thereby guaranteeing that it would be loaded -- that is, in Initialize.c, where XtToolkitInitialize() and XtInitialize() reside. These routines would normally be called. You are probably seeing this error because your program is not a normal Xt-based program and does not call XtToolkitInitialize() anywhere. 1) it may be a program that uses Xt functions but never opens a connection to the X server. [OSF/Motif's 1.1.0 UIL had this problem; it called XtMalloc() and other Xt functions.] The solution is to add the call to your program; the function does not have to be executed, just linked in. 2) alternatively, your program doesn't need any Xt functions and is correct in not calling XtToolkitInitialize() -- it may be an Xlib or XView program. In this case, you can remove -lXt from your link command. It should not be necessary to link the shared libraries statically, although this will certainly solve the problem. [from Jordan Hayes (now jordan@tcs.COM) and Danny Backx (db@sunbim.be); 11/90] ---------------------------------------------------------------------- Subject: 90) Why can't I compile my R3 Xaw contrib programs under R4? I have a program that worked well under X11R3. When I try to link it under X11R4, I get this message: Undefined: _XtScrollBarSetThumb _XtTextSetInsertionPoint _XtTextReplace There were several name changes in the Athena widget set (in addition to the header files moving into <X11/Xaw/>); these are mentioned in the R4 release notes. In this case, these functions are not really Xt functions but are part of the Xaw text widget and so have been renamed from Xt* to Xaw*. [10/90] ---------------------------------------------------------------------- Subject: 91) TOPIC: PROGRAMMING PROBLEMS AND PUZZLES ---------------------------------------------------------------------- Subject: 92) Why doesn't my program get the keystrokes I select for? The window manager controls how the input focus is transferred from one window to another. In order to get keystrokes, your program must ask the window manager for the input focus. To do this, you must set up what are called "hints" for the window manager. If your applications is Xlib-based, you can use something like the following: XWMHints wmhints; ... wmhints.flags = InputHint; wmhints.input = True; XSetWMHints(dpy, window, &hints) If your application is based on the Xt Intrinsics, you can set the XtNinput resource to be True (as you probably want to in any case); if you don't have source, you can start up the application with the resource '*input:True'. Certain window managers, notably dxwm and olwm, are very picky about having this done. If you are using Sun's OpenWindows olwm, you can also add this resource to your defaults file to use clients that aren't ICCCM-compliant. OpenWindows.FocusLenience: true [mostly courtesy Dave Lemke of NCD and Stuart Marks of Sun] ---------------------------------------------------------------------- Subject: 93) Is there a skeleton X program available? There is no general framework such as the TransSkel program for the Macintosh which handles lots of the odds and ends and overhead of development under a window system and which can be used as a platform for additional development. In X, the problem is typically solved by using an interactive application builder tool or by using cut&paste on existing X applications. Good applications which you might look to manipulate when you want to "test just this one little thing" include contrib/clients/xskel, a simple R4 program that puts up a window and allows sketching in it and offers a starting point for quick hacks, the Xaw examples in the examples/ directory in the R3 and R4 distributions, and the Xlib "Hello World" example in the R3 doc/HelloWorld and R4 doc/tutorials/HelloWorld; an updated version of this program which uses R4 Xlib calls and current ICCCM conventions was posted in 2/90 to comp.windows.x by Glenn Widener of Tektronix. [3/90] ---------------------------------------------------------------------- Subject: 94) Why does XtGetValues not work for me? The XtGetValues interface for retrieving resources from a widget is sensitive to the type of variable. Your code may be doing something like this: { Arg args[3]; int i; int sensitive; /* oops */ i=0; XtSetArg (args[i], XtNsensitive, &sensitive); i++; XtGetValues(widget, args, i ); ... } But XtNsensitive is a Boolean, which on most machines is a single byte; declaring the variable "sensitive" as Boolean works properly. This problem comes up often when using particular toolkits that redefine the Xt types Dimension and Position; code that assumes they are int will have similar problems if those types are actually short. In general: you are safe if you use the actual type of the resource, as it appears in the widget's man page. [11/90] ---------------------------------------------------------------------- Subject: 95) Why don't XtConfigureWidget/XtResizeWidget/XtMoveWidget work? You're probably trying to use these functions from application code. They should be used only internally to widgets; these functions are for a parent widget to change the geometry of its children. Other promising functions, XtMakeGeometryRequest() and XtMakeResizeRequest(), are also for use only by widgets, in this case by a child to request a change from its parent. The only way for your application to request a geometry change for a widget is to issue an XtSetValues call setting some of the geometry resources. Although this will result in the widget-internal functions' being called, your application code must use the standard XtSetValues interface or risk the widgets' data becoming corrupted. ---------------------------------------------------------------------- Subject: 96) How can my application tell if it is being run under X? A number of programs offer X modes but otherwise run in a straight character-only mode. The easiest way for an application to determine that it is running on an X display is to attempt to open a connection to the X server: display = XOpenDisplay((char *)NULL); if (display) { do X stuff } else { do curses or something else } This is superior to checking for a -display command-line argument or checking for $DISPLAY set in the environment, neither of which is adequate. [1/91] ---------------------------------------------------------------------- Subject: 97) How do I make a "busy cursor" while my application is computing? Is it necessary to call XDefineCursor() for every window in my application? The easiest thing to do is to create a single InputOnly window that is as large as the screen; make it a child of your toplevel window and it will be clipped to that window, so it won't affect any other application. (It needs to be as big as the screen in case the user enlarges the window while it is busy.) Substitute "toplevel" with your top-most widget here (similar code should work for Xlib-only applications; just use your top Window): unsigned long valuemask; XSetWindowAttributes attributes; /* Ignore device events while the busy cursor is displayed. */ valuemask = CWDontPropagate | CWCursor; attributes.do_not_propagate_mask = (KeyPressMask | KeyReleaseMask | ButtonPressMask | ButtonReleaseMask | PointerMotionMask); attributes.cursor = XCreateFontCursor(XtDisplay(toplevel), XC_watch); /* The window will be as big as the display screen, and clipped by its own parent window, so we never have to worry about resizing */ XCreateWindow(XtDisplay(toplevel), XtWindow(toplevel), 0, 0, WidthOfScreen(XtScreen(toplevel)), HeightOfScreen(XtScreen(toplevel)), (unsigned int) 0, CopyFromParent, InputOnly, CopyFromParent, valuemask, &attributes); When you want to use this busy cursor, map and raise this window; to go back to normal, unmap it. This will automatically keep you from getting extra mouse events; depending on precisely how the window manager works, it may or may not have a similar effect on keystrokes as well. In addition, note also that most of the Xaw widgets support an XtNcursor resource which can be temporarily reset, should you merely wish to change the cursor without blocking pointer events. [thanks to Andrew Wason (aw@cellar.bae.bellcore.com), Dan Heller (argv@sun.com), and mouse@LARRY.MCRCIM.MCGILL.EDU] [11/90] ---------------------------------------------------------------------- Subject: 98) How do I query the user synchronously using Xt? It is possible to have code which looks like this trivial callback, which has a clear flow of control. The calls to AskUser() block until answer is set to one of the valid values. If it is not a "yes" answer, the code drops out of the callback and back to an event-processing loop: void quit(w, client, call) Widget w; XtPointer client, call; { int answer; answer = AskUser(w, "Really Quit?"); if (RET_YES == answer) { answer = AskUser(w, "Are You Really Positive?"); if (RET_YES == answer) exit(0); } } A more realistic example might ask whether to create a file or whether to overwrite it. This is accomplished by entering a second event-processing loop and waiting until the user answers the question; the answer is returned to the calling function. That function AskUser() looks something like this, where the Motif can be replaced with widget-set-specific code to create some sort of dialog-box displaying the question string and buttons for "OK", "Cancel" and "Help" or equivalents: int AskUser(w, string) Widget w; char *string; { int answer=RET_NONE; /* some not-used marker */ Widget dialog; /* could cache&carry, but ...*/ Arg args[3]; int n = 0; XtAppContext context; n=0; XtSetArg(args[n], XmNmessageString, XmStringCreateLtoR(string, XmSTRING_DEFAULT_CHARSET)); n++; XtSetArg(args[n], XmNdialogStyle, XmDIALOG_APPLICATION_MODAL); n++; dialog = XmCreateQuestionDialog(XtParent(w), string, args, n); XtAddCallback(dialog, XmNokCallback, response, &answer); XtAddCallback(dialog, XmNcancelCallback, response, &answer); XtAddCallback(dialog, XmNhelpCallback, response, &answer); XtManageChild(dialog); context = XtWidgetToApplicationContext (w); while (answer == RET_NONE || XtAppPending(context)) { XtAppProcessEvent (context, XtIMAll); } XtDestroyWidget(dialog); /* blow away the dialog box and shell */ return answer; } The dialog supports three buttons, which are set to call the same function when tickled by the user. The variable answer is set when the user finally selects one of those choices: void response(w, client, call) Widget w; XtPointer client; XtPointer call; { int *answer = (int *) client; XmAnyCallbackStruct *reason = (XmAnyCallbackStruct *) call; switch (reason->reason) { case XmCR_OK: *answer = RET_YES; /* some #define value */ break; case XmCR_CANCEL: *answer = RET_NO; break; case XmCR_HELP: *answer = RET_HELP; break; default: return; } } and the code unwraps back to the point at which an answer was needed and continues from there. [Thanks to Dan Heller (argv@sun.com); further code is in Dan's R3/contrib WidgetWrap library. 2/91] ---------------------------------------------------------------------- Subject: 99) How do I fork without hanging my parent X program? An X-based application which spawns off other Unix processes which continue to run after it is closed typically does not vanish until all of its children are terminated; the children inherit from the parent the open X connection to the display. What you need to do is fork; then, immediately, in the child process, close (ConnectionNumber(XtDisplay(widget))); to close the file-descriptor in the display information. After this do your exec. You will then be able to exit the parent. [Thanks to Janet Anstett (anstettj@tramp.Colorado.EDU) and Gordon Freedman (gjf00@duts.ccc.amdahl.com) 2/91] ---------------------------------------------------------------------- Subject: 100) Why does XtAppAddInput not work as described? I am using XtAppAddInput to read from a file, but the function is called even when there isn't input pending. XtAppAddInput is actually working as it is supposed to. When used on files, it is called whenever the file is READY to be read, not when there is new data to be read. The file is almost always ready to be read, however, if only because you can spin back to the beginning and read data you've read before. The result is that your function will almost always be called every time around XtMainLoop(). To get the type of interaction you are expecting, add this line to the beginning of your function to test whether there is new data: if (ioctl(fd, FIONREAD, &n) == -1 || n == 0) return; [courtesy Dan Heller (argv@ora.com); 8/90] ---------------------------------------------------------------------- Subject: 101) How do I simulate a button press/release event for a widget? You can do this using XSendEvent(); it's likely that you're not setting the window field in the event, which Xt needs in order to match to the widget which should receive the event. If you're sending events to your own application, then you can use XtDispatchEvent() instead. This is more efficient than XSendEvent() in that you avoid a round-trip to the server. [courtesy Mark A. Horstman (mh2620@sarek.sbc.com), 11/90] ---------------------------------------------------------------------- Subject: 102) Why doesn't anything appear when I run this simple program? > ... > the_window = XCreateSimpleWindow(the_display, > root_window,size_hints.x,size_hints.y, > size_hints.width,size_hints.height,BORDER_WIDTH, > BlackPixel(the_display,the_screen), > WhitePixel(the_display,the_screen)); > ... > XSelectInput(the_display,the_window,ExposureMask|ButtonPressMask| > ButtonReleaseMask); > XMapWindow(the_display,the_window); > ... > XDrawLine(the_display,the_window,the_GC,5,5,100,100); > ... You are right to map the window before drawing into it. However, the window is not ready to be drawn into until it actually appears on the screen -- until your application receives an Expose event. Drawing done before that will generally not appear. You'll see code like this in many programs; this code would appear after window was created and mapped: while (!done) { XNextEvent(the_display,&the_event); switch (the_event.type) { case Expose: /* On expose events, redraw */ XDrawLine(the_display,the_window,the_GC,5,5,100,100); break; ... } } Note that there is a second problem: some X servers don't set up the default graphics context to have reasonable foreground/background colors, and your program should not assume that the server does, so this program could previously include this code to prevent the case of having the foreground and background colors the same: ... the_GC_values.foreground=BlackPixel(the_display,the_screen); /* e.g. */ the_GC_values.background=WhitePixel(the_display,the_screen); /* e.g. */ the_GC = XCreateGC(the_display,the_window, GCForeground|GCBackground,&the_GC_values); ... Note: the code uses BlackPixel and WhitePixel to avoid assuming that 1 is black and 0 is white or vice-versa. The relationship between pixels 0 and 1 and the colors black and white is implementation-dependent. They may be reversed, or they may not even correspond to black and white at all. ---------------------------------------------------------------------- Subject: 103) What is the difference between a Screen and a screen? The 'Screen' is an Xlib structure which includes the information about one of the monitors or virtual monitors which a single X display supports. A server can support several independent screens. They are numbered unix:0.0, unix:0.1, unix:0.2, etc; the 'screen' or 'screen_number' is the second digit -- the 0, 1, 2 which can be thought of as an index into the array of available Screens on this particular Display connection. The macros which you can use to obtain information about the particular Screen on which your application is running typically have two forms -- one which takes a Screen and one with takes both the Display and the screen_number. In Xt-based programs, you typically use XtScreen(widget) to determine the Screen on which your application is running, if it uses a single screen. (Part of the confusion may arise from the fact that some of the macros which return characteristics of the Screen have "Display" in the names -- XDisplayWidth, XDisplayHeight, etc.) ---------------------------------------------------------------------- Subject: 104)* Can I use C++ with X11R4? Motif? The X11R4 header files are compatible with C++. The Motif 1.1 header files are usable as is inside extern "C" {...}. However, the definition of String in Intrinsic.h can conflict with the libg++ or other String class and needs to be worked around. Some other projects which can help, esp. with prototyped header files for other versions of X, include: - WWL, a set of C++ classes by Jean-Daniel Fekete to wrap X Toolkit widgets, available via anonymous FTP from export.lcs.mit.edu as contrib/WWL-1.1.tar.Z and lri.lri.fr (129.175.15.1) as pub/WWL-1.1.tar.Z. - X++, also a wrapper set, available from the University of Lowell Graphics Research Laboratory/Motif. Contact Fran Ward at 508-934-3628. - THINGS, a class library written at the Rome Air Force Base by the Strategic Air Command, available as freeware on archive sites. - HP C++ 2.0 with Motif 1.0. [2.1 is about to ship.] - InterViews 3.0 is now available as an alpha release [3/91]. It is obtainable via anonymous FTP from interviews.stanford.edu Also of likely use is Saber-C++. [Thanks to Douglas S. Rand (dsrand@mitre.org) and George Wu (gwu@tcs.com);2/91] ---------------------------------------------------------------------- Subject: 105) How do I determine the name of an existing widget? I have a widget ID and need to know what the name of that widget is. R4 users are best off using the XtName() function, which will work on both widgets and non-widget objects. If you are still using R3, you can use this simple bit of code to do what you want. Note that it depends on the widget's internal data structures and is not portable to future versions of Xt, including R4. #include <X11/CoreP.h> String XtName (widget) Widget widget; /* will not work with non-widget objects */ { return widget->core.name; } [7/90] ---------------------------------------------------------------------- Subject: 106) What widget is appropriate to use as a drawing canvas? Some widget sets have a widget particularly for this purpose -- a WorkSpace or DrawingArea which doesn't display anything but lets your Xt application know when it has been re-exposed, resized, and when it has received user key and mouse input. The best thing to do for other widget sets -- including the Athena set -- is to create or obtain such a widget; this is preferable to drawing into a core widget and grabbing events with XtAddEventHandler(), which loses a number of benefits of Xt and encapsulation of the functionality . At least one version has been posted to comp.sources.x (name???). The publicly-available programs xball and xpic include other versions. And Chapter 7 of the Athena Widget manual includes a tutorial and source code to a simple Window widget which is suitable for use. ---------------------------------------------------------------------- Subject: 107) Why do I get a BadDrawable error drawing to XtWindow(widget)? I'm doing this in order to get a window into which I can do Xlib graphics within my Xt-based program: > canvas = XtCreateManagedWidget ( ...,widgetClass,...) /* drawing area */ > ... > window = XtWindow(canvas); /* get the window associated with the widget */ > ... > XDrawLine (...,window,...); /* produces error */ The window associated with the widget is created as a part of the realization of the widget. Using a window id of NULL ("no window") could create the error that you describe. It is necessary to call XtRealizeWidget() before attempting to use the window associated with a widget. Note that the window will be created after the XtRealizeWidget() call, but that the server may not have actually mapped it yet, so you should also wait for an Expose event on the window before drawing into it. ---------------------------------------------------------------------- Subject: 108) Can XGetWindowAttributes get a window's background pixel/pixmap? No. Once set, the background pixel or pixmap of a window cannot be re-read by clients. The reason for this is that a client can create a pixmap, set it to be the background pixmap of a window, and then free the pixmap. The window keeps this background, but the pixmap itself is destroyed. If you're sure a window has a background pixel (not a pixmap), you can use XClearArea() to clear a region to the background color and then use XGetImage() to read back that pixel. However, this action alters the contents of the window, and it suffers from race conditions with exposures. [courtesy Dave Lemke of NCD and Stuart Marks of Sun] Note that the same applies to the border pixel/pixmap. This is a (mis)feature of the protocol which allows the server is free to manipulate the pixel/pixmap however it wants. By not requiring the server to keep the original pixel or pixmap, some (potentially a lot of) space can be saved. [courtesy Jim Fulton, MIT X Consortium] ---------------------------------------------------------------------- Subject: 109) Why doesn't GXxor produce mathematically-correct color values? When using GXxor you may expect that drawing with a value of black on a background of black, for example, should produce white. However, the drawing operation does not work on RGB values but on colormap indices. The color that the resulting colormap index actually points to is undefined and visually random unless you have actually filled it in yourself. [On many X servers Black and White often 0/1 or 1/0; programs taking advantage of this mathematical coincidence will break.] If you want to be combining colors with GXxor, then you should be allocating a number of your own color cells and filling them with your chosen pre-computed values. If you want to use GXxor simply to switch between two colors, then you can take the shortcut of setting the background color in the GC to 0 and the foreground color to a value such that when it draws over red, say, the result is blue, and when it draws over blue the result is red. This foreground value is itself the XOR of the colormap indices of red and blue. [Thanks to Chris Flatters (cflatter@zia.aoc.nrao.EDU) and Ken Whaley (whaley@spectre.pa.dec.com), 2/91] ---------------------------------------------------------------------- Subject: 110) Why does the pixmap I copy to the screen show up as garbage? The initial contents of pixmaps are undefined. This means that most servers will allocate the memory and leave around whatever happens to be there -- which is usually garbage. You probably want to clear the pixmap first using XFillRectangle() with a function of GXcopy and a foreground pixel of whatever color you want as your background (or 0L if you are using the pixmap as a mask). [courtesy Dave Lemke of NCD and Stuart Marks of Sun] ---------------------------------------------------------------------- Subject: 111) How can my application iconify itself? The ICCCM provides a mechanism for this; your application sends a client message which includes a data value indicating that it wishes to be iconified. Here is a sample callback that will iconify the application shell, wait 3 seconds, and pop it back up. Note that ApplicationShellWidget below is global; it would make more sense in real use to walk up the tree via XtParent() to find the shell containing the active widget. void IconifyShell(w, d1, d2) Widget w; caddr_t d1, d2; { XClientMessageEvent event; Window win; Display *dpy; event.type = ClientMessage; event.send_event = True; dpy = event.display = XtDisplay(w); win = event.window = XtWindow(ApplicationShellWidget); event.message_type = XInternAtom(dpy, "WM_CHANGE_STATE", False); event.format = 32; event.data.l[0] = IconicState; XSendEvent(dpy, DefaultRootWindow(dpy), False, SubstructureRedirectMask | SubstructureNotifyMask, &event); XFlush(dpy); sleep(3); XMapWindow(dpy,win); } [courtesy David Brooks (dbrooks@osf.osf.org), 4/90] R4 users may find it easier to use this routine: /* * This function instructs the window manager to change this window from * NormalState to IconicState. */ Status XIconifyWindow (dpy, w, screen) Display *dpy; Window w; int screen; ---------------------------------------------------------------------- Subject: 112) How do I check whether a window ID is valid? My program has the ID of a window on a remote display. I want to check whether the window exists before doing anything with it. Because X is asynchronous, there isn't a guarantee that the window would still exist between the time that you got the ID and the time you sent an event to the window or otherwise manipulated it. What you should do is send the event without checking, but install an error handler to catch any BadWindow errors, which would indicate that the window no longer exists. This scheme will work except on the [rare] occasion that the original window has been destroyed and its ID reallocated to another window. [courtesy Ken Lee (klee@wsl.dec.com), 4/90] ---------------------------------------------------------------------- Subject: 113)* Why can't my program work with tvtwm or swm? A number of applications, including xwd, xwininfo, and xsetroot, do not handle the virtual root window which tvtwm and swm use; they typically return the wrong child of root. A general solution is to add this code or to use it in your own application where you would normally use RootWindow(dpy,screen): /* Function Name: GetVRoot * Description: Gets the root window, even if it's a virtual root * Arguments: the display and the screen * Returns: the root window for the client */ #include <X11/Xatom.h> Window GetVRoot(dpy, scr) Display *dpy; int scr; { Window rootReturn, parentReturn, *children; unsigned int numChildren; Window root = RootWindow(dpy, scr); Atom __SWM_VROOT = None; int i; __SWM_VROOT = XInternAtom(dpy, "__SWM_VROOT", False); XQueryTree(dpy, root, &rootReturn, &parentReturn, &children, &numChildren); for (i = 0; i < numChildren; i++) { Atom actual_type; int actual_format; long nitems, bytesafter; Window *newRoot = NULL; if (XGetWindowProperty(dpy, children[i], __SWM_VROOT, 0, 1, False, XA_WINDOW, &actual_type, &actual_format, &nitems, &bytesafter, (unsigned char **) &newRoot) == Success && newRoot) { root = *newRoot; break; } } return root; } [courtesy David Elliott (dce@smsc.sony.com). Similar code is in ssetroot, a version of xsetroot distributed with tvtwm. 2/91] A header file by Andreas Stolcke of ICSI on export.lcs.mit.edu:contrib/vroot.h functions similarly by providing macros for RootWindow and DefaultRootWindow; code can include this header file first to run properly in the presence of a virtual desktop. ---------------------------------------------------------------------- Subject: 114) Can I have two applications draw to the same window? Yes. The X server assigns IDs to windows and other resources, and any application that knows the ID can manipulate the resource. The problem you face is how to disseminate the window ID to multiple applications. A simple way to handle this (and which solves the problem of the applications' running on different machines) is in the first application to create a specially-named property on the root-window and put the window ID into it. The second application then retrieves the property, whose name it also knows, and then can draw whatever it wants into the window. [Note: this scheme works iff there is only one instance of the first application running, and the scheme is subject to the limitations mentioned in the Question about using window IDs on remote displays.] Note also that you will still need to coordinate any higher-level cooperation among your applications. Note also that two processes can share a window but should not try to use the same server connection. If one process is a child of the other, it should close down the connection to the server and open its own connection. [mostly courtesy Phil Karlton (karlton@wpd.sgi.com) 6/90] ---------------------------------------------------------------------- Subject: 115) How do I keep a window from being resized by the user? Resizing the window is done through the window manager; window managers can pay attention to the size hints your application places on the window, but there is no guarantee that the window manager will listen. You can try setting the minimum and maximum size hints to your target size and hope for the best. [1/91] ---------------------------------------------------------------------- Subject: 116)* How do I render rotated text? Xlib intentionally does not provide such sophisticated graphics capabilities, leaving them up to server-extensions or clients-side graphics libraries. Your only choice, if you want to stay within the core X protocol, is to render the text into a pixmap, read it back via XGetImage(), rotate it "by hand" with whatever matrices you want, and put it back to the server via XPutImage(); more specifically: 1) create a bitmap B and write your text to it. 2) create an XYBitmap image I from B (via XGetImage). 3) create an XYBitmap Image I2 big enough to handle the transformation. 4) for each x,y in I2, I2(x,y) = I(a,b) where a = x * cos(theta) - y * sin(theta) b = x * sin(theta) + y * cos(theta) 5) render I2 Note that you should be careful how you implement this not to lose bits; an algorithm based on shear transformations may in fact be better. The high-level server-extensions and graphics packages available for X also permit rendering of rotated text: Display PostScript, PEX, PHIGS, and GKS, although most are not capable of arbitrary rotation and probably do not use the same fonts that would be found on a printer. In addition, if you have enough access to the server to install a font on it, you can create a font which consists of letters rotated at some predefined angle. Your application can then itself figure out placement of each glyph. [courtesy der Mouse (mouse@larry.mcrcim.mcgill.edu), Eric Taylor (etaylor@wilkins.bmc.tmc.edu), and Ken Lee (klee@wsl.dec.com), 11/90; Liam Quin (lee@sq.com), 12/90] InterViews (C++ UI toolkit, in the X contrib software) has support for rendering rotated fonts in X. It could be one source of example code. [Brian R. Smith (brsmith@cs.umn.edu), 3/91] ---------------------------------------------------------------------- Subject: 117) Why can't my program get a standard colormap? I have an image-processing program which uses XGetRGBColormap() to get the standard colormap, but it doesn't work. XGetRGBColormap() when used with the property XA_RGB_DEFAULT_MAP does not create a standard colormap -- it just returns one if one already exists. Use xstdcmap or do what it does in order to create the standard colormap first. [1/91; from der Mouse (mouse@larry.mcrcim.mcgill.edu)] ---------------------------------------------------------------------- Subject: 118) What is the X Registry? (How do I reserve names?) There are places in the X Toolkit, in applications, and in the X protocol that define and use string names. The context is such that conflicts are possible if different components use the same name for different things. The MIT X Consortium maintains a registry of names in these domains: orgainization names, selection names, selection targets, resource types, application classes, and class extension record types; and several others. The list as of 1/90 is in the directory mit/doc/Registry on the R4 tape. To register names (first come, first served) or to ask questions send to xregistry@expo.lcs.mit.edu; be sure to include a postal address for confirmation. [11/90; condensed from Asente/Swick Appendix H] -- The X User's Group xug@expo.lcs.mit.edu "No, I'm a member of the X User's Group, not the Ex-user's Group."
xug@lta.com (X User's Group) (05/06/91)
[Last changed: 05 May 91] This article contains the last of four parts of a set of answers to some Frequently Asked Questions (FAQ) often seen in comp.windows.x. It is posted to help reduce volume in this newsgroup and to provide hard-to-find information of general interest. Please redistribute this article! ---------------------------------------------------------------------- Subject: 94) TOPIC: PROGRAMMING PROBLEMS AND PUZZLES ---------------------------------------------------------------------- Subject: 95) Why doesn't my program get the keystrokes I select for? The window manager controls how the input focus is transferred from one window to another. In order to get keystrokes, your program must ask the window manager for the input focus. To do this, you must set up what are called "hints" for the window manager. If your applications is Xlib-based, you can use something like the following: XWMHints wmhints; ... wmhints.flags = InputHint; wmhints.input = True; XSetWMHints(dpy, window, &hints) If your application is based on the Xt Intrinsics, you can set the XtNinput resource to be True (as you probably want to in any case); if you don't have source, you can start up the application with the resource '*input:True'. Certain window managers, notably dxwm and olwm, are very picky about having this done. If you are using Sun's OpenWindows olwm, you can also add this resource to your defaults file to use clients that aren't ICCCM-compliant. OpenWindows.FocusLenience: true [mostly courtesy Dave Lemke of NCD and Stuart Marks of Sun] ---------------------------------------------------------------------- Subject: 96) Is there a skeleton X program available? There is no general framework such as the TransSkel program for the Macintosh which handles lots of the odds and ends and overhead of development under a window system and which can be used as a platform for additional development. In X, the problem is typically solved by using an interactive application builder tool or by using cut&paste on existing X applications. Good applications which you might look to manipulate when you want to "test just this one little thing" include contrib/clients/xskel, a simple R4 program that puts up a window and allows sketching in it and offers a starting point for quick hacks, the Xaw examples in the examples/ directory in the R3 and R4 distributions, and the Xlib "Hello World" example in the R3 doc/HelloWorld and R4 doc/tutorials/HelloWorld; an updated version of this program which uses R4 Xlib calls and current ICCCM conventions was posted in 2/90 to comp.windows.x by Glenn Widener of Tektronix. [3/90] ---------------------------------------------------------------------- Subject: 97) Why does XtGetValues not work for me? The XtGetValues interface for retrieving resources from a widget is sensitive to the type of variable. Your code may be doing something like this: { Arg args[3]; int i; int sensitive; /* oops */ i=0; XtSetArg (args[i], XtNsensitive, &sensitive); i++; XtGetValues(widget, args, i ); ... } But XtNsensitive is a Boolean, which on most machines is a single byte; declaring the variable "sensitive" as Boolean works properly. This problem comes up often when using particular toolkits that redefine the Xt types Dimension and Position; code that assumes they are int will have similar problems if those types are actually short. In general: you are safe if you use the actual type of the resource, as it appears in the widget's man page. [11/90] ---------------------------------------------------------------------- Subject: 98) Why don't XtConfigureWidget/XtResizeWidget/XtMoveWidget work? You're probably trying to use these functions from application code. They should be used only internally to widgets; these functions are for a parent widget to change the geometry of its children. Other promising functions, XtMakeGeometryRequest() and XtMakeResizeRequest(), are also for use only by widgets, in this case by a child to request a change from its parent. The only way for your application to request a geometry change for a widget is to issue an XtSetValues call setting some of the geometry resources. Although this will result in the widget-internal functions' being called, your application code must use the standard XtSetValues interface or risk the widgets' data becoming corrupted. ---------------------------------------------------------------------- Subject: 99) How can my application tell if it is being run under X? A number of programs offer X modes but otherwise run in a straight character-only mode. The easiest way for an application to determine that it is running on an X display is to attempt to open a connection to the X server: display = XOpenDisplay((char *)NULL); if (display) { do X stuff } else { do curses or something else } This is superior to checking for a -display command-line argument or checking for $DISPLAY set in the environment, neither of which is adequate. [1/91] ---------------------------------------------------------------------- Subject: 100) How do I make a "busy cursor" while my application is computing? Is it necessary to call XDefineCursor() for every window in my application? The easiest thing to do is to create a single InputOnly window that is as large as the screen; make it a child of your toplevel window and it will be clipped to that window, so it won't affect any other application. (It needs to be as big as the screen in case the user enlarges the window while it is busy.) Substitute "toplevel" with your top-most widget here (similar code should work for Xlib-only applications; just use your top Window): unsigned long valuemask; XSetWindowAttributes attributes; /* Ignore device events while the busy cursor is displayed. */ valuemask = CWDontPropagate | CWCursor; attributes.do_not_propagate_mask = (KeyPressMask | KeyReleaseMask | ButtonPressMask | ButtonReleaseMask | PointerMotionMask); attributes.cursor = XCreateFontCursor(XtDisplay(toplevel), XC_watch); /* The window will be as big as the display screen, and clipped by its own parent window, so we never have to worry about resizing */ XCreateWindow(XtDisplay(toplevel), XtWindow(toplevel), 0, 0, WidthOfScreen(XtScreen(toplevel)), HeightOfScreen(XtScreen(toplevel)), (unsigned int) 0, CopyFromParent, InputOnly, CopyFromParent, valuemask, &attributes); When you want to use this busy cursor, map and raise this window; to go back to normal, unmap it. This will automatically keep you from getting extra mouse events; depending on precisely how the window manager works, it may or may not have a similar effect on keystrokes as well. In addition, note also that most of the Xaw widgets support an XtNcursor resource which can be temporarily reset, should you merely wish to change the cursor without blocking pointer events. [thanks to Andrew Wason (aw@cellar.bae.bellcore.com), Dan Heller (argv@sun.com), and mouse@LARRY.MCRCIM.MCGILL.EDU] [11/90] ---------------------------------------------------------------------- Subject: 101) How do I query the user synchronously using Xt? It is possible to have code which looks like this trivial callback, which has a clear flow of control. The calls to AskUser() block until answer is set to one of the valid values. If it is not a "yes" answer, the code drops out of the callback and back to an event-processing loop: void quit(w, client, call) Widget w; XtPointer client, call; { int answer; answer = AskUser(w, "Really Quit?"); if (RET_YES == answer) { answer = AskUser(w, "Are You Really Positive?"); if (RET_YES == answer) exit(0); } } A more realistic example might ask whether to create a file or whether to overwrite it. This is accomplished by entering a second event-processing loop and waiting until the user answers the question; the answer is returned to the calling function. That function AskUser() looks something like this, where the Motif can be replaced with widget-set-specific code to create some sort of dialog-box displaying the question string and buttons for "OK", "Cancel" and "Help" or equivalents: int AskUser(w, string) Widget w; char *string; { int answer=RET_NONE; /* some not-used marker */ Widget dialog; /* could cache&carry, but ...*/ Arg args[3]; int n = 0; XtAppContext context; n=0; XtSetArg(args[n], XmNmessageString, XmStringCreateLtoR(string, XmSTRING_DEFAULT_CHARSET)); n++; XtSetArg(args[n], XmNdialogStyle, XmDIALOG_APPLICATION_MODAL); n++; dialog = XmCreateQuestionDialog(XtParent(w), string, args, n); XtAddCallback(dialog, XmNokCallback, response, &answer); XtAddCallback(dialog, XmNcancelCallback, response, &answer); XtAddCallback(dialog, XmNhelpCallback, response, &answer); XtManageChild(dialog); context = XtWidgetToApplicationContext (w); while (answer == RET_NONE || XtAppPending(context)) { XtAppProcessEvent (context, XtIMAll); } XtDestroyWidget(dialog); /* blow away the dialog box and shell */ return answer; } The dialog supports three buttons, which are set to call the same function when tickled by the user. The variable answer is set when the user finally selects one of those choices: void response(w, client, call) Widget w; XtPointer client; XtPointer call; { int *answer = (int *) client; XmAnyCallbackStruct *reason = (XmAnyCallbackStruct *) call; switch (reason->reason) { case XmCR_OK: *answer = RET_YES; /* some #define value */ break; case XmCR_CANCEL: *answer = RET_NO; break; case XmCR_HELP: *answer = RET_HELP; break; default: return; } } and the code unwraps back to the point at which an answer was needed and continues from there. [Thanks to Dan Heller (argv@sun.com); further code is in Dan's R3/contrib WidgetWrap library. 2/91] ---------------------------------------------------------------------- Subject: 102) How do I fork without hanging my parent X program? An X-based application which spawns off other Unix processes which continue to run after it is closed typically does not vanish until all of its children are terminated; the children inherit from the parent the open X connection to the display. What you need to do is fork; then, immediately, in the child process, close (ConnectionNumber(XtDisplay(widget))); to close the file-descriptor in the display information. After this do your exec. You will then be able to exit the parent. [Thanks to Janet Anstett (anstettj@tramp.Colorado.EDU) and Gordon Freedman (gjf00@duts.ccc.amdahl.com) 2/91] ---------------------------------------------------------------------- Subject: 103) Why does XtAppAddInput not work as described? I am using XtAppAddInput to read from a file, but the function is called even when there isn't input pending. XtAppAddInput is actually working as it is supposed to. When used on files, it is called whenever the file is READY to be read, not when there is new data to be read. The file is almost always ready to be read, however, if only because you can spin back to the beginning and read data you've read before. The result is that your function will almost always be called every time around XtMainLoop(). To get the type of interaction you are expecting, add this line to the beginning of your function to test whether there is new data: if (ioctl(fd, FIONREAD, &n) == -1 || n == 0) return; [courtesy Dan Heller (argv@ora.com); 8/90] ---------------------------------------------------------------------- Subject: 104) How do I simulate a button press/release event for a widget? You can do this using XSendEvent(); it's likely that you're not setting the window field in the event, which Xt needs in order to match to the widget which should receive the event. If you're sending events to your own application, then you can use XtDispatchEvent() instead. This is more efficient than XSendEvent() in that you avoid a round-trip to the server. [courtesy Mark A. Horstman (mh2620@sarek.sbc.com), 11/90] ---------------------------------------------------------------------- Subject: 105) Why doesn't anything appear when I run this simple program? > ... > the_window = XCreateSimpleWindow(the_display, > root_window,size_hints.x,size_hints.y, > size_hints.width,size_hints.height,BORDER_WIDTH, > BlackPixel(the_display,the_screen), > WhitePixel(the_display,the_screen)); > ... > XSelectInput(the_display,the_window,ExposureMask|ButtonPressMask| > ButtonReleaseMask); > XMapWindow(the_display,the_window); > ... > XDrawLine(the_display,the_window,the_GC,5,5,100,100); > ... You are right to map the window before drawing into it. However, the window is not ready to be drawn into until it actually appears on the screen -- until your application receives an Expose event. Drawing done before that will generally not appear. You'll see code like this in many programs; this code would appear after window was created and mapped: while (!done) { XNextEvent(the_display,&the_event); switch (the_event.type) { case Expose: /* On expose events, redraw */ XDrawLine(the_display,the_window,the_GC,5,5,100,100); break; ... } } Note that there is a second problem: some X servers don't set up the default graphics context to have reasonable foreground/background colors, and your program should not assume that the server does, so this program could previously include this code to prevent the case of having the foreground and background colors the same: ... the_GC_values.foreground=BlackPixel(the_display,the_screen); /* e.g. */ the_GC_values.background=WhitePixel(the_display,the_screen); /* e.g. */ the_GC = XCreateGC(the_display,the_window, GCForeground|GCBackground,&the_GC_values); ... Note: the code uses BlackPixel and WhitePixel to avoid assuming that 1 is black and 0 is white or vice-versa. The relationship between pixels 0 and 1 and the colors black and white is implementation-dependent. They may be reversed, or they may not even correspond to black and white at all. ---------------------------------------------------------------------- Subject: 106) What is the difference between a Screen and a screen? The 'Screen' is an Xlib structure which includes the information about one of the monitors or virtual monitors which a single X display supports. A server can support several independent screens. They are numbered unix:0.0, unix:0.1, unix:0.2, etc; the 'screen' or 'screen_number' is the second digit -- the 0, 1, 2 which can be thought of as an index into the array of available Screens on this particular Display connection. The macros which you can use to obtain information about the particular Screen on which your application is running typically have two forms -- one which takes a Screen and one with takes both the Display and the screen_number. In Xt-based programs, you typically use XtScreen(widget) to determine the Screen on which your application is running, if it uses a single screen. (Part of the confusion may arise from the fact that some of the macros which return characteristics of the Screen have "Display" in the names -- XDisplayWidth, XDisplayHeight, etc.) ---------------------------------------------------------------------- Subject: 107)* Can I use C++ with X11R4? Motif? The X11R4 header files are compatible with C++. The Motif 1.1 header files are usable as is inside extern "C" {...}. However, the definition of String in Intrinsic.h can conflict with the libg++ or other String class and needs to be worked around. Some other projects which can help, esp. with prototyped header files for other versions of X, include: - WWL, a set of C++ classes by Jean-Daniel Fekete to wrap X Toolkit widgets, available via anonymous FTP from export.lcs.mit.edu as contrib/WWL-1.1.tar.Z and lri.lri.fr (129.175.15.1) as pub/WWL-1.1.tar.Z. - X++, also a wrapper set, available from the University of Lowell Graphics Research Laboratory/Motif. Contact Fran Ward at 508-934-3628. - THINGS, a class library written at the Rome Air Force Base by the Strategic Air Command, available as freeware on archive sites. - HP C++ 2.0 with Motif 1.0. [2.1 is about to ship.] - InterViews 3.0 is now available as an alpha release [3/91]. It is obtainable via anonymous FTP from interviews.stanford.edu Also of likely use is Saber-C++. [Thanks to Douglas S. Rand (dsrand@mitre.org) and George Wu (gwu@tcs.com);2/91] ---------------------------------------------------------------------- Subject: 108) How do I determine the name of an existing widget? I have a widget ID and need to know what the name of that widget is. R4 users are best off using the XtName() function, which will work on both widgets and non-widget objects. If you are still using R3, you can use this simple bit of code to do what you want. Note that it depends on the widget's internal data structures and is not portable to future versions of Xt, including R4. #include <X11/CoreP.h> String XtName (widget) Widget widget; /* will not work with non-widget objects */ { return widget->core.name; } [7/90] ---------------------------------------------------------------------- Subject: 109) What widget is appropriate to use as a drawing canvas? Some widget sets have a widget particularly for this purpose -- a WorkSpace or DrawingArea which doesn't display anything but lets your Xt application know when it has been re-exposed, resized, and when it has received user key and mouse input. The best thing to do for other widget sets -- including the Athena set -- is to create or obtain such a widget; this is preferable to drawing into a core widget and grabbing events with XtAddEventHandler(), which loses a number of benefits of Xt and encapsulation of the functionality . At least one version has been posted to comp.sources.x (name???). The publicly-available programs xball and xpic include other versions. And Chapter 7 of the Athena Widget manual includes a tutorial and source code to a simple Window widget which is suitable for use. ---------------------------------------------------------------------- Subject: 110) Why do I get a BadDrawable error drawing to XtWindow(widget)? I'm doing this in order to get a window into which I can do Xlib graphics within my Xt-based program: > canvas = XtCreateManagedWidget ( ...,widgetClass,...) /* drawing area */ > ... > window = XtWindow(canvas); /* get the window associated with the widget */ > ... > XDrawLine (...,window,...); /* produces error */ The window associated with the widget is created as a part of the realization of the widget. Using a window id of NULL ("no window") could create the error that you describe. It is necessary to call XtRealizeWidget() before attempting to use the window associated with a widget. Note that the window will be created after the XtRealizeWidget() call, but that the server may not have actually mapped it yet, so you should also wait for an Expose event on the window before drawing into it. ---------------------------------------------------------------------- Subject: 111) Can XGetWindowAttributes get a window's background pixel/pixmap? No. Once set, the background pixel or pixmap of a window cannot be re-read by clients. The reason for this is that a client can create a pixmap, set it to be the background pixmap of a window, and then free the pixmap. The window keeps this background, but the pixmap itself is destroyed. If you're sure a window has a background pixel (not a pixmap), you can use XClearArea() to clear a region to the background color and then use XGetImage() to read back that pixel. However, this action alters the contents of the window, and it suffers from race conditions with exposures. [courtesy Dave Lemke of NCD and Stuart Marks of Sun] Note that the same applies to the border pixel/pixmap. This is a (mis)feature of the protocol which allows the server is free to manipulate the pixel/pixmap however it wants. By not requiring the server to keep the original pixel or pixmap, some (potentially a lot of) space can be saved. [courtesy Jim Fulton, MIT X Consortium] ---------------------------------------------------------------------- Subject: 112) Why doesn't GXxor produce mathematically-correct color values? When using GXxor you may expect that drawing with a value of black on a background of black, for example, should produce white. However, the drawing operation does not work on RGB values but on colormap indices. The color that the resulting colormap index actually points to is undefined and visually random unless you have actually filled it in yourself. [On many X servers Black and White often 0/1 or 1/0; programs taking advantage of this mathematical coincidence will break.] If you want to be combining colors with GXxor, then you should be allocating a number of your own color cells and filling them with your chosen pre-computed values. If you want to use GXxor simply to switch between two colors, then you can take the shortcut of setting the background color in the GC to 0 and the foreground color to a value such that when it draws over red, say, the result is blue, and when it draws over blue the result is red. This foreground value is itself the XOR of the colormap indices of red and blue. [Thanks to Chris Flatters (cflatter@zia.aoc.nrao.EDU) and Ken Whaley (whaley@spectre.pa.dec.com), 2/91] ---------------------------------------------------------------------- Subject: 113) Why does the pixmap I copy to the screen show up as garbage? The initial contents of pixmaps are undefined. This means that most servers will allocate the memory and leave around whatever happens to be there -- which is usually garbage. You probably want to clear the pixmap first using XFillRectangle() with a function of GXcopy and a foreground pixel of whatever color you want as your background (or 0L if you are using the pixmap as a mask). [courtesy Dave Lemke of NCD and Stuart Marks of Sun] ---------------------------------------------------------------------- Subject: 114) How can my application iconify itself? The ICCCM provides a mechanism for this; your application sends a client message which includes a data value indicating that it wishes to be iconified. Here is a sample callback that will iconify the application shell, wait 3 seconds, and pop it back up. Note that ApplicationShellWidget below is global; it would make more sense in real use to walk up the tree via XtParent() to find the shell containing the active widget. void IconifyShell(w, d1, d2) Widget w; caddr_t d1, d2; { XClientMessageEvent event; Window win; Display *dpy; event.type = ClientMessage; event.send_event = True; dpy = event.display = XtDisplay(w); win = event.window = XtWindow(ApplicationShellWidget); event.message_type = XInternAtom(dpy, "WM_CHANGE_STATE", False); event.format = 32; event.data.l[0] = IconicState; XSendEvent(dpy, DefaultRootWindow(dpy), False, SubstructureRedirectMask | SubstructureNotifyMask, &event); XFlush(dpy); sleep(3); XMapWindow(dpy,win); } [courtesy David Brooks (dbrooks@osf.osf.org), 4/90] R4 users may find it easier to use this routine: /* * This function instructs the window manager to change this window from * NormalState to IconicState. */ Status XIconifyWindow (dpy, w, screen) Display *dpy; Window w; int screen; ---------------------------------------------------------------------- Subject: 115) How do I check whether a window ID is valid? My program has the ID of a window on a remote display. I want to check whether the window exists before doing anything with it. Because X is asynchronous, there isn't a guarantee that the window would still exist between the time that you got the ID and the time you sent an event to the window or otherwise manipulated it. What you should do is send the event without checking, but install an error handler to catch any BadWindow errors, which would indicate that the window no longer exists. This scheme will work except on the [rare] occasion that the original window has been destroyed and its ID reallocated to another window. [courtesy Ken Lee (klee@wsl.dec.com), 4/90] ---------------------------------------------------------------------- Subject: 116)* Why can't my program work with tvtwm or swm? A number of applications, including xwd, xwininfo, and xsetroot, do not handle the virtual root window which tvtwm and swm use; they typically return the wrong child of root. A general solution is to add this code or to use it in your own application where you would normally use RootWindow(dpy,screen): /* Function Name: GetVRoot * Description: Gets the root window, even if it's a virtual root * Arguments: the display and the screen * Returns: the root window for the client */ #include <X11/Xatom.h> Window GetVRoot(dpy, scr) Display *dpy; int scr; { Window rootReturn, parentReturn, *children; unsigned int numChildren; Window root = RootWindow(dpy, scr); Atom __SWM_VROOT = None; int i; __SWM_VROOT = XInternAtom(dpy, "__SWM_VROOT", False); XQueryTree(dpy, root, &rootReturn, &parentReturn, &children, &numChildren); for (i = 0; i < numChildren; i++) { Atom actual_type; int actual_format; long nitems, bytesafter; Window *newRoot = NULL; if (XGetWindowProperty(dpy, children[i], __SWM_VROOT, 0, 1, False, XA_WINDOW, &actual_type, &actual_format, &nitems, &bytesafter, (unsigned char **) &newRoot) == Success && newRoot) { root = *newRoot; break; } } return root; } [courtesy David Elliott (dce@smsc.sony.com). Similar code is in ssetroot, a version of xsetroot distributed with tvtwm. 2/91] A header file by Andreas Stolcke of ICSI on export.lcs.mit.edu:contrib/vroot.h functions similarly by providing macros for RootWindow and DefaultRootWindow; code can include this header file first to run properly in the presence of a virtual desktop. ---------------------------------------------------------------------- Subject: 117) Can I have two applications draw to the same window? Yes. The X server assigns IDs to windows and other resources, and any application that knows the ID can manipulate the resource. The problem you face is how to disseminate the window ID to multiple applications. A simple way to handle this (and which solves the problem of the applications' running on different machines) is in the first application to create a specially-named property on the root-window and put the window ID into it. The second application then retrieves the property, whose name it also knows, and then can draw whatever it wants into the window. [Note: this scheme works iff there is only one instance of the first application running, and the scheme is subject to the limitations mentioned in the Question about using window IDs on remote displays.] Note also that you will still need to coordinate any higher-level cooperation among your applications. Note also that two processes can share a window but should not try to use the same server connection. If one process is a child of the other, it should close down the connection to the server and open its own connection. [mostly courtesy Phil Karlton (karlton@wpd.sgi.com) 6/90] ---------------------------------------------------------------------- Subject: 118) How do I keep a window from being resized by the user? Resizing the window is done through the window manager; window managers can pay attention to the size hints your application places on the window, but there is no guarantee that the window manager will listen. You can try setting the minimum and maximum size hints to your target size and hope for the best. [1/91] ---------------------------------------------------------------------- Subject: 119)* How do I render rotated text? Xlib intentionally does not provide such sophisticated graphics capabilities, leaving them up to server-extensions or clients-side graphics libraries. Your only choice, if you want to stay within the core X protocol, is to render the text into a pixmap, read it back via XGetImage(), rotate it "by hand" with whatever matrices you want, and put it back to the server via XPutImage(); more specifically: 1) create a bitmap B and write your text to it. 2) create an XYBitmap image I from B (via XGetImage). 3) create an XYBitmap Image I2 big enough to handle the transformation. 4) for each x,y in I2, I2(x,y) = I(a,b) where a = x * cos(theta) - y * sin(theta) b = x * sin(theta) + y * cos(theta) 5) render I2 Note that you should be careful how you implement this not to lose bits; an algorithm based on shear transformations may in fact be better. The high-level server-extensions and graphics packages available for X also permit rendering of rotated text: Display PostScript, PEX, PHIGS, and GKS, although most are not capable of arbitrary rotation and probably do not use the same fonts that would be found on a printer. In addition, if you have enough access to the server to install a font on it, you can create a font which consists of letters rotated at some predefined angle. Your application can then itself figure out placement of each glyph. [courtesy der Mouse (mouse@larry.mcrcim.mcgill.edu), Eric Taylor (etaylor@wilkins.bmc.tmc.edu), and Ken Lee (klee@wsl.dec.com), 11/90; Liam Quin (lee@sq.com), 12/90] InterViews (C++ UI toolkit, in the X contrib software) has support for rendering rotated fonts in X. It could be one source of example code. [Brian R. Smith (brsmith@cs.umn.edu), 3/91] ---------------------------------------------------------------------- Subject: 120) Why can't my program get a standard colormap? I have an image-processing program which uses XGetRGBColormap() to get the standard colormap, but it doesn't work. XGetRGBColormap() when used with the property XA_RGB_DEFAULT_MAP does not create a standard colormap -- it just returns one if one already exists. Use xstdcmap or do what it does in order to create the standard colormap first. [1/91; from der Mouse (mouse@larry.mcrcim.mcgill.edu)] ---------------------------------------------------------------------- Subject: 121) What is the X Registry? (How do I reserve names?) There are places in the X Toolkit, in applications, and in the X protocol that define and use string names. The context is such that conflicts are possible if different components use the same name for different things. The MIT X Consortium maintains a registry of names in these domains: orgainization names, selection names, selection targets, resource types, application classes, and class extension record types; and several others. The list as of 1/90 is in the directory mit/doc/Registry on the R4 tape. To register names (first come, first served) or to ask questions send to xregistry@expo.lcs.mit.edu; be sure to include a postal address for confirmation. [11/90; condensed from Asente/Swick Appendix H] -- David B. Lewis for XUG The X User's Group xug@expo.lcs.mit.edu "No, I'm a member of the X User's Group, not the Ex-user's Group."