arthur@media.uucp (Art Poley) (07/14/90)
I am trying to implement a 256 element PseudoColor colormap under X/motif for image processing applications. The palette will initially be linear and via pseudocolor, contrast, and other imaging operations may be dynamically altered. Using the calls XCreateColormap, XAllocColorCells, and XStoreColor I have been able to create a linear mapping. I then use XSetWindowColormap to associate this mapping to the toplevel application shell. Unfortunately, the colors used by the window manager have been lost. Does anyone know how to preserve the colors used by the motif window manager within my 256 element colormap? Basically, I would like to create a (256 - N) element colormap. Where N would be the number of colors needed to preserve the 3D-look, menus, etc. used by the mwm. Due to the dynamic nature of the imaging colormap, sharing of colormaps does not seem like a good approach. I'd really just assume that N out of my 256 are reserved for the window manager. Hopefully N won't be to large (16 or less?). If anyone has any suggestions, references, etc., I'd really appreciate it. Thanks! Art -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |\/\/\/\/| | | | | | (e) (e) _______________________ | _) / | (c ,_____\ / Oh, Yeah, Right! | | (__( < | | / \ Don't have a cow, man.| /____\ \_______________________| / \ Art Poley - Media Cybernetics Phone: (301)495-3305 Internet: arthur%media@uunet.uu.net UUCP: {uunet,hqda-ai}!media!arthur ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
tyager@maxx.UUCP (Tom Yager) (07/16/90)
In article <1990Jul13.183517.23734@media.uucp>, arthur@media.uucp (Art Poley) writes: > Does anyone know how to preserve the colors used by the motif window manager > within my 256 element colormap? Basically, I would like to create a (256 - N) > element colormap. Where N would be the number of colors needed to preserve > the 3D-look, menus, etc. used by the mwm. Due to the dynamic nature of the > imaging colormap, sharing of colormaps does not seem like a good approach. > I'd really just assume that N out of my 256 are reserved for the window manager. > Hopefully N won't be to large (16 or less?). > > If anyone has any suggestions, references, etc., I'd really appreciate it. > Art Poley - Media Cybernetics Phone: (301)495-3305 > Internet: arthur%media@uunet.uu.net UUCP: {uunet,hqda-ai}!media!arthur If you use XSetWindowColormap() to install the colormap, and mwm's colormapFocusPolicy resource is set to "keyboard," then that window's map should be active whenever it has input focus. When you shift focus away from that window, the default colormap (and, therefore, mwm's shading) should be restored. Is that not sufficient? Writing your application to set aside a fixed number of colors for external use is possible, but limiting. I'm a little shaky on this; one of the others may want to correct or clarify: You can replace the system's default colormap, allocating all but 16 cells for your own use. Then, programs which run after this change wouldn't touch your colors. I'd say that's "breaking the rules," however, since you're making serious assumptions about what other applications the user will want to run alongside your own. This approach also requires that you restart the window manager and other applications after you've reset the map. That's a pain, too. The best-behaved thing to do, I think, is either to install a window-bound colormap, or just use the default map. Keep allocating colors until you run out, and apply your color transforms based on the number of colors you get. The Motif-based Mandelbrot generator I've written uses that policy, and that helps it to run well on anything from monochrome to 8-plane. I give the user the option (at run time) whether to use a private colormap. Good luck. (ty) -- +--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ | NET: decvax!maxx!tyager -or- uunet!bytepb!maxx!tyager | | I speak only for myself "UNIX: It's not a job, | +-------------------------------------it's a Jihad!" -co-worker------------+
dce@smsc.sony.com (David Elliott) (07/16/90)
In article <59@maxx.UUCP> tyager@maxx.UUCP (Tom Yager) writes: >If you use XSetWindowColormap() to install the colormap, and mwm's >colormapFocusPolicy resource is set to "keyboard," then that window's map >should be active whenever it has input focus. When you shift focus away from >that window, the default colormap (and, therefore, mwm's shading) should be >restored. Is that not sufficient? I think that the question came up because it isn't acceptable. In general, I feel that just blindly installing a new colormap makes people less likely to want to use your application. When the application with the new colormap gets focus, the window manager colors get messed up, and focus changes can be very annoying because colors are changing everywhere. Also, the application in question is doing colormap animation, and if the cells used for animation are the same ones used for drawing window manager window borders or icons, the screen can go ape. A good example of installing a colormap that isn't obtrusive can be found in xcycle. This program allocates a new colormap, but uses cells starting at number 255 instead of 0, and thus almost never uses cells that are already being used, even with full-color root backgrounds. The only complaint I have about xcycle is that you can't tell it not to allocate a new colormap. Sometimes, you just want to use the cells. The algorithm given by der Mouse is probably the best way to go, with the additional user-option to use the default colormap if it's large enough. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."You know my motto: Forgive and uh... the other thing."
dce@smsc.sony.com (David Elliott) (07/16/90)
In article <1990Jul16.134303.2465@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: |> The algorithm given by der Mouse is probably the best way to go, with |> the additional user-option to use the default colormap if it's large |> enough. Oops. I really meant something intelligent here. By "if it's large enough", I meant "if it has enough free cells". As a side note, it seems to me that the color cell allocation routines in X could remember the last cell allocated and start there unless otherwise directed. This would mean that color backgrounds created by connections that no longer exist would stay correct longer, and that programs that allocate private colormaps would generally start using unused cells first. Or, maybe it would be good enough to add a "allocate from the end of the colormap and go backwards" option to the color cell allocation routines. ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."You know my motto: Forgive and uh... the other thing."
yee@osf.org (Michael K. Yee) (07/17/90)
In article <1990Jul13.183517.23734@media.uucp> arthur@media.uucp (Art Poley) writes: > I am trying to implement a 256 element PseudoColor colormap under X/motif > for image processing applications. The palette will initially be linear > and via pseudocolor, contrast, and other imaging operations may be dynamically > altered. Using the calls XCreateColormap, XAllocColorCells, and XStoreColor > I have been able to create a linear mapping. I then use XSetWindowColormap > to associate this mapping to the toplevel application shell. Unfortunately, > the colors used by the window manager have been lost. > > Does anyone know how to preserve the colors used by the motif window manager > within my 256 element colormap? Basically, I would like to create a (256 - N) > element colormap. Where N would be the number of colors needed to preserve > the 3D-look, menus, etc. used by the mwm. Due to the dynamic nature of the > imaging colormap, sharing of colormaps does not seem like a good approach. > I'd really just assume that N out of my 256 are reserved for the window manager. > Hopefully N won't be to large (16 or less?). > What you are asking to do will not be easy. So, I'll answer the question you didn't ask. And that question is "How do I get the Motif window manager to allocate only TWO colors (i.e. foreground and background) for imaging applications)? The answer is set the following resources and restart Mwm. If you replace "black" and "white" with the colors you are using as your foreground and background colors, you should have 254 colors at your disposal. !! MWM 1.0 - MONOCHROME setup Mwm*cleanText: True Mwm*activeBackground: white Mwm*activeForeground: black Mwm*background: white Mwm*foreground: black Mwm*client*activeBackgroundPixmap: 50_foreground Mwm*client*activeTopShadowPixmap: foreground Mwm*client*activeBottomShadowPixmap: background Mwm*client*backgroundPixmap: 75_foreground Mwm*client*topShadowPixmap: foreground Mwm*client*bottomShadowPixmap: background Mwm*feedback*backgroundPixmap: 50_foreground Mwm*menu*backgroundPixmap: foreground Mwm*icon*activeBackgroundPixmap: 50_foreground Mwm*icon*activeBottomShadowPixmap: foreground Mwm*icon*backgroundPixmap: 75_foreground > If anyone has any suggestions, references, etc., I'd really appreciate it. > > Thanks! > > Art > -- Happy windowing, =Mike -- = Michael K. Yee =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = OPEN Software Foundation -- 11 Cambridge Center -- Cambridge, MA 02142 = Phone: 617-621-8831 Email: yee@osf.org, uunet!osf.org!yee = "I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
Uucp@resq.fidonet.org (Uucp) (03/27/91)
From uunet!osf.org!motif-talk-request From: uunet!osf.org!dbrooks To: motif@alfalfa.com, motif-talk@osf.org Date: Tue, 26 Mar 91 09:19:41 -0500 Kee wrote: >2. Given a widget that needs an it's own colormap, what do I do to notify the > windowmanager? Asente and Swick say to use XtSetWMColormapWindows after > the widget is realized. The Xt Ref manual doesn't mention the call, and > using it doesn't seem to do anything (although I need to double check and > make sure it's realized again). Has anyone done this? Yes; the call is in section 11.10 of the Xt reference that comes with the tape. As I read it, you need to give it both a shell widget and a list of widgets who have private colormaps. I've only done it with a shell that has a private colormap inherited by all its children, not individual cmaps per widget; this code works (although it's in the process of being improved). The order of events is significant. After these calls, the wm color focus policy will install at the appropriate time. Of course, you need a decent window manager :-) ... dpy = XtDisplay(toplevel); scrn = XtScreen(toplevel); vis = DefaultVisualOfScreen(scrn); cmap = XCreateColormap(dpy, XtWindow(toplevelW), vis, AllocNone); WorkAroundVisualBug(cmap); n = 0; XtSetArg(args[n], XmNcolormap, cmap), n++; /* etc */ shell = XtCreatePopupShell("shell", topLevelShellWidgetClass, toplevelW, _ARGS(shellWargs)); /* Now you can populate the shell with its contents and manage them */ XtRealizeWidget(shell); XtSetWMColormapWindows(shell, &shell, 1); /* Cheap trick WidgetList */ XtPopup(shell, XtGrabNone); ... /* Visual.c (at least up to 1.1.3, maybe more) assumes that all colormaps * have the standard two pixels initialized the same as root, and uses these * pixel values for default foreground and sometimes background. Here we * try to meet that expectation. Unfortunately, we have to assume that * XAllocColor will allocate the entries in order 0, 1. */ static void WorkAroundVisualBug(cmap) Colormap cmap; { XColor colors[2]; Colormap default_cmap = DefaultColormapOfScreen(scrn); colors[0].pixel = 0; colors[1].pixel = 1; XQueryColors(dpy, default_cmap, colors, 2); XAllocColor(dpy, cmap, &colors[0]); XAllocColor(dpy, cmap, &colors[1]); } -- Uucp - via FidoNet node 1:269/133 UUCP: uunet!resq!Uucp