kma%nil.utah.edu@cs.utah.edu (Kwan-Liu Ma) (10/25/89)
Hi,
I have some problem dealing with colormap in X11:
I create a private colormap for a specific window as follows:
my_cmap = XCreateColormap(display, win, visual, AllocAll);
XSetWindowColormap(dipaly, win, my_cmap);
for (i = 0; i<64; i++) {
Color[i].pixel = i;
Color[i].red = ...
Color[i].green = ...
Color[i].blue = ...
...
}
XStoreColors(display, cmap, Color, 64);
Later in my program, I use
XCreateGC(display, win, ...);
XSetForeground(display, gc, Color[i].pixel);
XFillRectangle(display, win, gc, ...);
to form some images.
It turns out that I always get colors from the default colormap
instead of the private one. Where did I do wrong??
Thanks for any help !!
-- Kwanconverse@EXPO.LCS.MIT.EDU (Donna Converse) (10/26/89)
> I create a private colormap for a specific window as follows: > > my_cmap = XCreateColormap(display, win, visual, AllocAll); > XSetWindowColormap(dipaly, win, my_cmap); This notifies the window manager that this window should have your private colormap installed when the window gets the input focus. The colormap should be installed immediately, so as a side effect, if your program has already opened a window on the screen, you may be able to see the colormap change as your program is running. However, some R3 window managers ignore your colormap request, and while running under those particular window managers, you must install and uninstall the colormap yourself. When running under window managers that do not ignore the colormap request, you must not install and uninstall the colormap from your application. > for (i = 0; i<64; i++) { > Color[i].pixel = i; > Color[i].red = ... > Color[i].green = ... > Color[i].blue = ... > ... You set Color[i].flags = DoRed | DoGreen | DoBlue , don't you? > } > XStoreColors(display, cmap, Color, 64); cmap is the same as my_cmap, right? > > Later in my program, I use > > XCreateGC(display, win, ...); > XSetForeground(display, gc, Color[i].pixel); > XFillRectangle(display, win, gc, ...); > > to form some images. > > It turns out that I always get colors from the default colormap > instead of the private one. Where did I do wrong?? Other than the questions that I raised, your code looks fine. If you still have trouble, tell us the server and window manager that you are using. Donna Converse converse@expo.lcs.mit.edu
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (10/27/89)
>> I create a private colormap for a specific window as follows: >> my_cmap = XCreateColormap(display, win, visual, AllocAll); >> XSetWindowColormap(dipaly, win, my_cmap); > This notifies the window manager that this window should have your > private colormap installed when the window gets the input focus. Oops, is it not permitted for the window manager to separate keyboard focus from colormap focus? > The colormap should be installed immediately, Now wait a minute, I thought you said the colormap was installed when the program has keyboard focus. Or is the window manager required to immediately reassign keyboard focus whenever a window with a private colormap is created? Run that by me again? I thought PointerRoot focus was a permitted keyboard focus policy! (Oops, sorry, I get it now: the window manager warps the mouse to the new window! Yes, that must be it.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dshr@SUN.COM (David Rosenthal) (10/27/89)
> >> I create a private colormap for a specific window as follows: > > >> my_cmap = XCreateColormap(display, win, visual, AllocAll); > >> XSetWindowColormap(dipaly, win, my_cmap); > > > This notifies the window manager that this window should have your > > private colormap installed when the window gets the input focus. > > Oops, is it not permitted for the window manager to separate keyboard > focus from colormap focus? > Please read sections 4.1.2.8, 4.1.8 and 4.2.6 of the ICCCM. The policies that window managers enforce for keyboard focus and colormap installation have no neccessary relationship to one another. Clients should set the ID of each sub-window that they expect to have a colormap that is different from the top-level window's colormap in a property called WM_COLORMAP_WINDOWS on the top-level window. The order of these windows is significant - the earlier in the list the more likely the colormap is to be installed. Clients should then set the colormap attribute of the sub-windows. The window manager will notice these changes, and when it decides that the top-level window deserves to have its colormap(s) installed. will install the first colormap(s) from the list. The decision that the window deserves to have its maps installed is up to the WM - it may or may not have anything to do with the input focus. David.
csvsj@garnet.berkeley.edu (Steve Jacobson) (10/28/89)
In article <8910270827.AA14049@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: >>> I create a private colormap for a specific window as follows: > >>> my_cmap = XCreateColormap(display, win, visual, AllocAll); >>> XSetWindowColormap(dipaly, win, my_cmap); > >> This notifies the window manager that this window should have your >> private colormap installed when the window gets the input focus. > >Oops, is it not permitted for the window manager to separate keyboard >focus from colormap focus? > Finally! I commented about this and posted modifications to twm to seperate keyboard and color focus and didn't get a single reply or response. Until 24 bit displays rule, seperating keyboard and color focus is the best way to handle multiple colormaps on 8 bit pseudo color displays. "Technicolor flash" is eliminated; the colormap focus changes only when the user wants it to. Does anyone know of a window manager that optionally seperates keyboard and color focus? Steve
stroyan@hpfcdq.HP.COM (Mike Stroyan) (10/29/89)
> Does anyone know of a window manager that optionally seperates keyboard and > color focus? > > Steve The mwm window manager that comes with motif supports this option Mike Stroyan, stroyan@hpfcla.hp.com
tim@cunixc.cc.columbia.edu (Timothy Jones) (10/31/89)
In article <890043@hpfcdq.HP.COM> stroyan@hpfcdq.HP.COM (Mike Stroyan) writes: > The mwm window manager that comes with motif supports this option I'm sure this has been asked before, but exactly where can mwm be obtained? -- ======================================================================== Timothy Jones, Instructional Computing tim@columbia.edu Columbia University Center for Computing Activities (212) 854-8319
mouse@lightning.mcrcim.mcgill.EDU (11/09/90)
> I was trying to get a ray tracing program that someone else wrote to > work on my DECStation 5000/200. The program fails when it attempts > to display an image and I traced the problem down to a section of > code that creates a new colormap. Below is the code fragment that I > think is causing problems. [edited for compactness -dM] > i = XMatchVisualInfo(display, theScreen, depth, PseudoColor, &visualinfo); > if (!i) i = XMatchVisualInfo(display, theScreen, depth, TrueColor, &visualinfo); > if (!i) exit(1); > visual = visualinfo.visual; > rootw = RootWindow(display, theScreen); > theGC = DefaultGC(display, theScreen); > cmap = XCreateColormap(display, rootw, visual, AllocAll); > ... > XStoreColors(display, cmap, carray, CMAPSIZE); > The first call to XMatchVisualInfo always fails but the second call > succeeds so apparently the visual class is TrueColor. (Or rather, no PseudoColor visual is available but a TrueColor visual is. On color displays there often (usually?) is no "the" visual class.) > This causes the XCreateColormap call to fail with a BadMatch error. > I tried fixing this problem by passing AllocNone instead of AllocAll > but this caused a protection error when XStoreColors was called. The problem is that you simply can't treat PseudoColor and TrueColor the same. For PseudoColor you need to XCreateColormap(...,AllocAll); XStoreColors(...); whereas for TrueColor you simply XCreateColormap(...,AllocNone); Note though that if the *default* visual is a TrueColor then there is no need to create a new colormap; you can simply use the default. > Can anybody offer any insight into this problem and suggest a > workaround ? I would guess that the code was developed on a system with PseudoColor available, so the TrueColor code was untested. For a workaround, I would recommend remembering somewhere whether the visual is PseudoColor or TrueColor and doing the colormap differently, as I sketched above. Note that you need to take care that your pixel values are correct for the desired colors in the TrueColor case; you can't assign them yourself as you can for PseudoColor. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (11/10/90)
In article <273A3E4E.7858@ics.uci.edu>, tolani@buckaroo.ics.uci.edu (Deepak Tolani) writes: |> |> |> Being completely unfamiliar with Xlib. I'd appreciate any assistance from you |> X hackers out there. I was trying to get a ray tracing program that someone else |> wrote to work on my DECStation 5000/200. The program fails when it attempts to |> display an image and I traced the problem down to a section of code |> that creates a new colormap. Below is the code fragment that I think is |> causing problems. |> |> |> i = XMatchVisualInfo(display, theScreen, depth, PseudoColor, &visualinfo); |> if (!i) |> i = XMatchVisualInfo(display, theScreen, depth, TrueColor, &visualinfo); |> |> if (!i) |> exit(1); |> |> visual = visualinfo.visual; |> |> rootw = RootWindow(display, theScreen); |> theGC = DefaultGC(display, theScreen); |> cmap = XCreateColormap(display, rootw, visual, AllocAll); |> ... |> |> XStoreColors(display, cmap, carray, CMAPSIZE); |> |> |> This section of code can not run with a TrueColor Visual. The documentation says that XCreateColormap can not be given AllocNone with a TrueColor Visual. Also, XStoreColors is horribly wrong with a TrueColor visual (TrueColor is READ ONLY!). This code must be re-thoughtout to deal with a TrueColor visual. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776