chucko@ucscf.UCSC.EDU (90219000) (03/16/91)
1. Can I set the colormap resource in my resource file using Wcl? My colormap is a read/write virtual colormap which is refered to by the variable "cmap" in my program. "cmap" isn't even created until after the resource file is processed. Is there any way to set the stage ahead of time? 2. Does the Shell parent of my drawable also have to have its colormap resource set for the X11R4 window manager to take care of swapping colormaps? Chuck Stein NOARL chucko@ucscf.ucsc.edu
marbru@attc.UUCP (Martin Brunecky) (03/16/91)
In article <13455@darkstar.ucsc.edu> chucko@ucscf.UCSC.EDU (90219000) writes: > >1. Can I set the colormap resource in my resource file >using Wcl? My colormap is a read/write virtual colormap >which is refered to by the variable "cmap" in my program. >"cmap" isn't even created until after the resource file is >processed. Is there any way to set the stage ahead of time? If you can create your colormap *before* you create your widgets (right after initialization), you can use a concept similar to Wcl callback "registration". Write a "StringToColormap" resource convertor which looks into a list of previously registered colormaps. Write a routine that registers a colormap for the convertor. Another solution is to put everything into the Wcl creation callback, and use SetValues on the just created widget. The main problem, however, is the default StringToPixel converter. If you manage to specify the colormap at the widget creation time, the StringToPixel converter will be called for each XtRPixel resource - and it will try to alocate a read-only cell in your colormap. This may cause problems, if you want to use the entire colormap for writeable cells. Of course, you may overload the converter (as I do). > >2. Does the Shell parent of my drawable also have to have its >colormap resource set for the X11R4 window manager to take >care of swapping colormaps? > If you have a true R4 compliant window manager, no. Note there are few WM's which claim to deal with the WM_COLORMAP_WINDOWS property - but (like Motif 1.0 mwm) in fact they don't. So you are always safer if you can set the shell's colormap. When it comes to subwindows, the subwindow ID must be added to WM_COLORMAP_WINDOWS property to notify the WM that this window has a non-default colormap. Another gotcha. Even though core widget allows you to specify a colormap, it does not call XtSetWMColormapWindows. Most likely because the windows to set are only known in/after widget's realize method is called. So far, I haven't seen (other than in-house) widget that would deal with the issue. To summ it up. In Motif 1.0 (Xt R3++?) I ended up with a lots of add-on code, because whatever colormap support was there did not work at all. R4 seems to be in much beeter shape, but in this area you may still find gray spots. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404