willson@pdaeng.UUCP (Stephen Willson) (09/27/89)
Hello, We have just received version 1.0 of OpenLook which we are running on Sun-4s and Sun OS 4.0.3. The default visual for the X11/News server is static color. There is another visual which is pseudo color but it is not the default visual. Our problem: all of our widgets get created with the default, static color visual, and we can't find a way to tell Xt that we want to use a different visual. We need the other visual, obviously, so that we can have colormaps installed. We have grep'd the Xt source for X11R3 with fixes 1-9 and it appears that widget creation always inherits the visual of the parent window. We have looked in Oliver Jones' book on Xlib to make sure we understand the mechanics of visuals and colormaps, and we have looked in Doug Young's book on Xt, and, as I indicated we have grep'd the source code. I have also grep'd all the messages I have saved from comp.windows.x (5 MB worth) and I still can't find the answer. The X11/News server from Sun is the first server we have found that has static color as the default visual. Please, if any toolkit experts in netland can send us any suggestions, we would be most grateful. I suspect other people will be running into this soon enough so you may want to post to the net. Thanks in advance, Stephen Clarke-Willson Software Architect PDA Engineering Costa Mesa, CA 92626 714/540 8900 x291 willson@pda.com
swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/28/89)
In R3 it is not possible to change the default visual for existing widget classes. Any widget class which wishes to offer such a capability can do so in its own realize procedure. If you were to subclass TopLevelShell and add a resource in this subclass which provided control of the visual, you could then cause all the descendants of that shell to inherit the new visual type. In R4 the ShellWidget will have such a resource.
ldm@texhrc.UUCP (Lyle Meier) (09/29/89)
In article <8909271536.AA22775@quito.local>, willson@pdaeng.UUCP (Stephen Willson) writes: > Hello, > > We have just received version 1.0 of OpenLook which we are running on Sun-4s > and Sun OS 4.0.3. The default visual for the X11/News server is static > color. There is another visual which is pseudo color but it is not the > default visual. Our problem: all of our widgets get created with the default, > static color visual, and we can't find a way to tell Xt that we want to use > a different visual. We need the other visual, obviously, so that we can > have colormaps installed. We have grep'd the Xt source for X11R3 with fixes Since you have the source you could modify XtCreateWindow which does all the work for the Hp, DecWindows and Athena Toolkits in window creation, to get a pseudo color visual and pass that thru. You might save the returned depth and then dispense with the call on later calls to XtCreateWindow. This will make the static color visual invisible to Xt, and the pseudo color visual will be the one to be seen. Adding the check about depth != to 1 the code could improve efficency. Furhter you should only have to check the visual the first time, and just pass it thru there after. This will have the effect of not allowing widgets to set their visual, but should work as a kludge until R4 arrives. Lyle Meier uunet!nuchat!texhrc!ldm
janssen@holmes (Bill Janssen) (09/29/89)
In article <8909271536.AA22775@quito.local>, willson@pdaeng (Stephen Willson) writes: >We have just received version 1.0 of OpenLook which we are running on Sun-4s >and Sun OS 4.0.3. The default visual for the X11/News server is static >color. There is another visual which is pseudo color but it is not the >default visual. The pseudo-color visual can be made the default visual by setting the environment variable USE_MIT_VISUALS (to some value, say "t") before starting the server. The problem with this is that NeWS programs think that the default visual is static. This is not generally too bad, but the cursor seems to be solid black. This is documented in the man page for xnews. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
lemke@SUN.COM (Dave Lemke) (09/30/89)
From: arisia!janssen%holmes@lll-winken.llnl.gov (Bill Janssen) Date: 29 Sep 89 02:08:12 GMT In article <8909271536.AA22775@quito.local>, willson@pdaeng (Stephen Willson) writes: >We have just received version 1.0 of OpenLook which we are running on Sun-4s >and Sun OS 4.0.3. The default visual for the X11/News server is static >color. There is another visual which is pseudo color but it is not the >default visual. The pseudo-color visual can be made the default visual by setting the environment variable USE_MIT_VISUALS (to some value, say "t") before starting the server. The problem with this is that NeWS programs think that the default visual is static. This is not generally too bad, but the cursor seems to be solid black. This is documented in the man page for xnews. NeWS programs will use any read-only colors in the colormap, so if you start running X clients that take up these cells, NeWS colors will use the closest match. If anyone is interested in using this from NeWS, send me mail. The cursor problem is a bug. Here's a hack to hold you till the next release. It should just fail with a (different) error then. /* hack to fix the black-on-black xnews cursor bug */ /* it'll exit with an error, but don't worry about that */ /* it *is* a hack, after all... */ #include <X11/Xlib.h> main() { Display *dpy; /* X server connection */ Colormap cmap; XColor defs[256]; int num, i; dpy = XOpenDisplay(); cmap = XDefaultColormap(dpy, 0); for (num = 256; num > 10; num--) if (XAllocColorCells(dpy, cmap, False, (char *) 0, 0, defs, num)) break; defs[num].pixel = 255; defs[num].red = defs[num].green = defs[num].blue = 0; defs[num].flags = DoRed|DoGreen|DoBlue; defs[num - 1].pixel = 254; defs[num - 1].red = defs[num - 1].green = defs[num - 1].blue = 65535; defs[num - 1].flags = DoRed|DoGreen|DoBlue; XStoreColors(dpy,cmap,defs,num); XSync(dpy, 0); } Dave Lemke ARPA: lemke@sun.com Window Systems Group UUCP: ucbvax!sun!lemke Sun Microsystems, Inc.