naughton@sun.soe.clarkson.edu (Patrick Naughton) (04/12/88)
Does anyone have an example of an X11 application which creates its own reaad/write colormap and manages enter/leave notification to install/remove said colormap? I have written a program to read/display Sun rasterfiles and Compu$erve GIF files and am using the shared colormap model such that I can only have 256 colors allocated at once. This makes it impossible to display more than one image at once. I agree that the merits of multiple colormaps and causing the rest of the sceen to go "technicolor" when using the installed colormap are dubious, but I'd like to add the functionality none the less. If anyone wants the code for the rasterfile or GIF viewers feel free to send e-mail. I'll make them and some images available via ftp at a later date. ___________________________________________ -Patrick | | | Internet: naughton@sun.soe.clarkson.edu | | BITNET: naughton@CLUTX.BITNET | | uucp: {rpics, gould}!clutx!naughton | |___________________________________________| p.s. Re: xmac posting, I didn't notice `xpert@athena.mit.edu' in the CC: line when I replied to David's message till it was too late. Sorry about that. But since you all read it: Anyone who has Mac images that I didn't distribute (don't have) can ftp to sun.soe.clarkson.edu (128.153.12.3) and put them in ~ftp/submit. Thanks.
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/24/89)
> As you can see from reading the Inter-Client Communications > Conventions Manual, obedient applications are enjoined from ever > calling InstallColormap. Instead, applications that wish to install > a single colormap are encouraged to use ChangeWindowAttributes to set > that colomap as the colormap of their top-level window. So unlike most of X, colormaps don't (won't, shouldn't) work if there's no window manager running? (Or is the X server supposed to figure out that there's no wm running and do the InstallColormap itself? :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rws@EXPO.LCS.MIT.EDU (07/24/89)
So unlike most of X, colormaps don't (won't, shouldn't) work if there's
no window manager running?
Few things in life are perfect. X11 was "out" before the colormap facilities
had significant use. There is a definite tension between making clients act
the same both with and without a window manager, and making them work correctly
and reasonably. The ICCCM chooses the latter, which is by far the more
common case, and accepts that a window manager must be running for certain
expectations to be met. If your application needs to function when no window
manager is running, you can give it a command line flag or something to
distinguish the two cases.mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (09/21/89)
>> Is there a call that returns the number of un-allocated color cells >> in a Colormap? > There is no protocol request for this. The theory is that you should > just allocate along in whatever map you prefer, and if you run out, > use CopyColormapAndFree to move stuff over to a new map. I had an application once where I wanted not the number of free cells in a colormap, but rather, a *contiguous* set of cells in a colormap. Is there any way to do this? XAllocColorCells bids fair to be what I want, but the documentation I have speaks of the `contig' parameter as follows: contig Specifies a Boolean value that indicates whether the planes must be contiguous. .... If contig is True and if all masks are ORed together, a sin- gle contiguous set of bits set to 1 will be formed for GrayScale or PseudoColor and three contiguous sets of bits set to 1 (one within each pixel subfield) for DirectColor. It says nothing about the returned pixel values. Do I have to just allocate and then, if I get non-contiguous pixel values, deal with the situation as best I can? Or is there some way (perhaps contig does this and my documentation is out of date)? (What I wound up doing was creating a new colormap for the purpose, which I therefore knew was completely free for me to play around in. Ugh.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/21/89)
I had an application once where I wanted not the number of free cells
in a colormap, but rather, a *contiguous* set of cells in a colormap.
Is there any way to do this?
Nope.
Do I have to just
allocate and then, if I get non-contiguous pixel values, deal with the
situation as best I can?
Yep. Our standard colormap code stands on its proverbial ear something along
these lines.lee@iris.ucdavis.EDU (Peng Lee) (09/22/89)
In article <8909211213.AA20836@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: !> I had an application once where I wanted not the number of free cells !> in a colormap, but rather, a *contiguous* set of cells in a colormap. !> Is there any way to do this? !> !> Nope. XAllocColorPlanes will allocate a *contiguous* set of cells in a colormap.
envbvs@epb2.lbl.gov (Brian V. Smith) (09/22/89)
In article <5385@ucdavis.ucdavis.edu>, lee@iris.ucdavis.EDU (Peng Lee) writes:
< XAllocColorPlanes will allocate a *contiguous* set of cells in a colormap.
Sorry, XAllocColorPlanes will allocate contiguous PLANES, not cells.
For example, if you allocates two planes, plane 2 and 3 (counting from 0),
then you will get CELLS 0, 4, 8 and 12. Not quite contiguous.
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/22/89)
XAllocColorPlanes will allocate a *contiguous* set of cells in a colormap. Not that I can think of. Perhaps you could explain?
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (09/22/89)
>>> I had an application once where I wanted [...] a *contiguous* set >>> of cells in a colormap. Is there any way to do this? >> Nope. > XAllocColorPlanes will allocate a *contiguous* set of cells in a > colormap. To allocate read/write color resources for a DirectColor model, use XAllocColorPlanes. Unfortunately I wanted this for a PseudoColor visual. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/22/89)
Sorry, XAllocColorPlanes will allocate contiguous PLANES, not cells. Correct, as does XAllocColorCells. If you want to contiguous entries, you can round up to a power of 2^N, and use XAllocColorCells with npixels = 1 and nplanes = N and contig = True, you can treat the resulting values as "contiguous", subject to shift and an add (take the numbers 0 through 2^N-1, shift them up to the planemask, then add the base pixel). If you didn't want a power of 2, you can free the extras. This is not optimal, but it can be done.
harish@csl.ncsu.edu (Harish Hiriyannaiah) (10/03/89)
I am having trouble loading color maps in X11 r3 (also using HPWidgets).
I can set the Red and Blue LUTs with no problem for any or all of the 256
colors, but Green has me stumped. Here is the code that is used to load an
entire map (I have also tried permutations of XAllocColorCells for
read/write cells and XAllocColor for read/only cells with no success)
LoadColorMap returns a valid XColor array and correct number of colors.
Has anyone out there any suggestions ?
user_color = LoadColorMap(mapfilename,&num_usercolors);
if (num_usercolors > DisplayCells(disp,DefaultScreen(disp)))
num_usercolors = DisplayCells(disp,DefaultScreen(disp));
user_colormap = XCreateColormap(disp,root_window,default_visual,
AllocAll);
XStoreColors(disp,user_colormap,user_color,num_usercolors);
XSetWindowColormap(disp,root_window,user_colormap);
XInstallColormap(disp,user_colormap);
Comments:
disp = disp of Toplevel widget from XtInitialize.
root_window = root_window of Toplevel widget.
default_visual = default_visual of Toplevel widget.
user_color[i].flags = DoRed|DoGreen|DoBlue;
Environment: Ultrix 3.1, VaxStation 3100, HP Widgets. The server is a
DECStation 3100.
harish pu. hi. harish@ecebucolix.ncsu.edu
harish@ecelet.ncsu.edubmc@MYCROFT.MAYO.EDU (10/03/89)
I don't know if this wil help, but the code I use to set colormaps on a similar
system is:
1) get a visual I can modify easily (usually pseudocolor)
flag = XMatchVisualInfo (display, screen, 8, Pseudocolor, &VInfo);
screen_visual = flag ? VInfo.visual : DefaultVisual (display, screen);
2) load colormap (set cells to the number of cells in your colormap)
color.flags = DoRed | DoBlue | DoGreen;
for (i = 0; i < cells; i++) {
color.pixel = i;
color.red = color.blue = color.green = 65535L * i / cells;
/* grey scale example */
XStoreColor (display, cmap, &color);
}
Hope this helps.
--Bruce
----------------------------------------------------
Bruce M. Cameron bmc@bru.mayo.edu
Medical Sciences 1-14 (507) 284-3288
Mayo Foundation WD9CKW
Rochester, MN 55905
----------------------------------------------------kent@gnomee.pa.dec.com (Christopher A. Kent) (10/05/89)
I had the same problem, and came up with the following code. It's not pretty, and it doesn't leave the cells sharable, but it works.
static Bool
_AllocContiguousCells(dpy, cmap, pixels, npixels)
Display *dpy;
Colormap cmap;
unsigned long *pixels; /* filled in by routine */
int npixels;
{
unsigned long *waste = (unsigned long *)NULL;
int nwaste = 0;
Bool contig = False;
int status, i;
unsigned long masks = NULL;
while (!contig) {
status = XAllocColorCells(dpy, cmap, False, &masks, 0, pixels,
npixels);
if (!status)
break; /* can't get enough contiguous cells */
for (i=0; i < (npixels-1); i++) {
if (pixels[i] + 1 != pixels[i+1]) {
/* isn't contiguous, keep trying */
XFreeColors(dpy, cmap, &pixels[i+1], npixels - (i+1), 0);
if (!waste)
waste = (unsigned long *)malloc((i + 1) *
sizeof(unsigned long));
else
waste = (unsigned long *)realloc(waste, (nwaste +
(i + 1)) * sizeof(unsigned long));
bcopy(pixels, waste+nwaste, (i+1) * sizeof(unsigned long));
nwaste += (i+1);
break;
}
}
if (i == (npixels-1))
contig = True;
}
/* clean up and return 'contig' */
if (nwaste) {
XFreeColors(dpy, cmap, waste, nwaste, 0);
free(waste);
}
return (contig);
}
Chris Kent Western Software Laboratory Digital Equipment Corporation
kent@decwrl.dec.com decwrl!kent (415) 853-6639gropp-bill@CS.Yale.EDU (Bill Gropp) (11/18/89)
What is the best way to do the following:
I have an application that wants to have its own colormap for a window;
the colors in this window should be dynamic and defineable by the
application. The number of colors needed may be small relative to
the number of colors available on the server (for example, 8 colors
on an 8 plane system).
When my colormap is installed by the window manager, I'd like the
least damage done to other applications. In particular, I'd like
to maintain "WhitePixel" and "BlackPixel" as meaning "white" and
"black", even if it means adding additional colors to my colormap.
Currently, I create a colormap and use XAllocColor to set entries
in it. Under uwm and twm on a Sun, when my window's colormap is
installed, other windows that are in black and white only are unchanged.
On a dec3100 using dxwm, black stays black but white becomes red.
I understand that when one colormap is installed, other windows will
be displayed in false color (black and red in this case). What
I want to know is what is the Mechanism for preserving as much of
the "default" colormap as possible.
Thanks in advance.
Bill Groppmadd@world.std.com (jim frost) (11/21/89)
gropp-bill@CS.Yale.EDU (Bill Gropp) writes: >What is the best way to do the following: > I have an application that wants to have its own colormap for a window; > the colors in this window should be dynamic and defineable by the > application. [...] > When my colormap is installed by the window manager, I'd like the > least damage done to other applications. Since later in your note you say you're using XAllocColor, I assume "dynamic" doesn't mean "read/write". With that in mind, the more-or-less standard way to do this is to do XAllocColor calls on DefaultColormap(). If the allocation fails, use XCopyColormapAndFree() to get a new colormap, after which it's pretty likely that some other applications' colors will be reused. Most of the time it works great. This is fairly standard and is what I do for everything except image processing, where you have to allocate lots of writable colors. Should work fine for your application. Sample code abounds in the contrib directory. jim frost software tool & die madd@std.com
etaylor@krebs.bcm.tmc.edu (Eric Taylor) (03/15/90)
I am using the XtSetWMColormapWindows in my program. While swm seems
to be correct in handling it, twm seems to ignore it.
MY code segment is.
main()
{
Widget toplevel ;
Widget parent ;
Widget img1,img2 ;
Colormap cmap1,cmap2 ;
Widget imgs[3] ;
int nimgs = 0 ;
XImage *image1 ;
XImage *image2 ;
toplevel = XtInitialize(...) ;
parent = XtVaCreateManagedWidget( .... ) ;
/* Create the images and colormaps */
img1 = XtVaCreateManagedWidget("",an image widget class,parent,
XtNcolormap,cmap1,
XtNimage,image1,
NULL) ;
img2 = XtVaCreateManagedWidget("",an image widget class,parent,
XtNcolormap,cmap2,
XtNimage,image2,
NULL) ;
XtRealizeWidget(toplevel) ;
imgs[nimgs++] = img1 ;
imgs[nimgs++] = img2 ;
imgs[nimgs++] = toplevel ;
XtSetColormapWindows(toplevel,imgs,nimgs) ;
XtMainLoop() ;
}
When I examine the properties of the windows using a window property
viewer, all of thje properties, and attributes seem to be correct.
What is the problem?
Eric Taylor
Baylor College of Medicinetoml@ninja.Solbourne.COM (Tom LaStrange) (03/15/90)
> I am using the XtSetWMColormapWindows in my program. While swm seems > to be correct in handling it, twm seems to ignore it. swm tracks Enter and Leave Notify events on all windows specified in the WM_COLORMAP_WINDOWS property, twm doesn't. Using twm, you can switch colormaps using f.colormap "next" f.colormap "prev" f.colormap "default" -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (07/16/90)
> I am trying to implement a 256 element PseudoColor colormap [...]. > Using the [Xlib colormap calls] 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. One possibility is to figure out just which colormap cells mwm uses and then wire the knowledge of those cells into your program. This is ugly and nonportable (definitely not portable to other window managers, likely not portable to mwm on another server, possibly not even portable to other runs of mwm on the same server). The only other possibility that comes to mind is to find out which cells are taken in the default colormap and copy them. Herewith a brief description of how you might go about this. First, grab the server so as to avoid skew problems. Now use XAllocColors to allocate the rest of the default colormap. Remember which color values you managed to allocate; they're the ones you can use. (You may find that too few colors are available; other programs may have allocated out of the default map. In this case, I don't know what to do; you could refuse to run or perhaps ignore the existing allocations and go technicolor.) Create your own colormap. Copy the colors for all the pixels you *couldn't* allocate from the default map to your map. You can now ungrab the server. If you want to be really nice to other programs, repeat the above procedure periodically and adjust the cells you're using when necessary. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
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."
jimf@SABER.COM (07/16/90)
|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. Most of the code to do what you want is implemented in my xloadimage program in send.c, except that it allocates the colors shareable (when done in the default colormap) instead of read/write as you want. What you want to do is loop on an XAllocColorCells to allocate as many cells read/write as you can. You'll have to create a mapping of your image's pixel values to those returned by the server so that you can massage your image to fit these values. Code to do this massaging is also in send.c. Because the number of cells you can allocate is an unknown, you might want to put in a threshold value at which time you allocate a completely new colormap. This is what xloadimage does and it seems to work reasonably well. If you don't have xloadimage, it's available by anonymous ftp from expo.lcs.mit.edu in /contrib/xloadimage.1.06.tar.Z or I can email it to you. If you have further questions, feel free to email me directly. jim frost saber software jimf@saber.com
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
dwy47@unix.cis.pitt.edu (Deanna W Yang) (03/28/91)
Hi there. I am very new to the world of X programming so pardon me if I sound stupid or that I didn't read the books thorough enough... In my application, I need to allocate colorcells for 16 application defined colors (let's say I put them in appcolor[0]..appcolor[15]). Now I can use the colors (if I want blue, it gives me blue) just as I define them (RGB values). The problem is, when I need to do logics with the colors, like xoring, anding etc (e.g. white on blue gives yellow..etc), since I am not using the default colorcells, I can't get the correct color for the modes. Say if I draw boxes using the Xor mode, it won't give me the correct color. It's not as simple as blue (0001) on white (1111) xor gives yellow (1110) because there's no way to know what color cells are allocated (or is there?) and even if we know, there's no systemetic scheme to do the logics. Are there anyone (you guru's :-) ) out there who have the idea or the algorithm to solve my problem? I don't know if I explain the question well enough but I do need the help. In a nutshell....if XAllocateColorCells give back like 97, 98, 99... (they might not even be contiguous), what algorithm i can use to acheive the correct logics? Note that the allocated cells can be anything.... Thanks.....I need your help. Deanna
dwy47@unix.cis.pitt.edu (Deanna W Yang) (03/28/91)
Forgot to say....please reply through email please. Thank you. :-) D
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/28/91)
> I am very new to the world of X programming so pardon me if I sound > stupid or that I didn't read the books thorough enough... This is a relatively frequent question, but you shouldn't have much trouble with it. You are already past the first hurdle most people seem to get stuck on. Fortunately, your problem is solvable. > The problem is, when I need to do logics with the colors, like > xoring, anding etc (e.g. white on blue gives yellow..etc), since I am > not using the default colorcells, I can't get the correct color for > the modes. I don't know what you're doing with 16 colors, when there are only three color channels, if you expect to work with primary colors this way, but that's your business.... > It's not as simple as blue (0001) on white (1111) xor gives yellow > (1110) because there's no way to know what color cells are allocated > (or is there?) Well, you know what cells are allocated because they're returned by the allocation call. > and even if we know, there's no systemetic scheme to do the logics. Right. You have to get lucky and get cells that happen to have the relationships you want. Now, what's the solution I implicitly promised above? Simply this: you tell the server to give you cells that are related the way you want. To do this, you have to allocate read/write cells instead of read-only cells (minor wart, but more or less unavoidable). What you actually want is to have a group of color cells that have all but four bits equal, then those four bits give you the sixteen combinations you want. The routine to allocate colormap cells this way is XAllocColorCells; you would want to call it with nplanes=4 and npixels=1. If it's important that all four bits be adjacent (which I gather in your case it is not), you can set contig True; otherwise, set it False. Of course, you can't blindly use GXxor even in this case; you need to take care to avoid clearing the "common" bits. You can do this by setting the plane-mask in the GC or by being careful to set the foreground and background values to something appropriate for the operation in question, take your pick.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
ramakris@bloss.cs.vt.edu (S.Ramakrishnan) (04/02/91)
In article <9103280703.AA16051@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: >To do this, you have to allocate read/write cells instead of read-only >cells (minor wart, but more or less unavoidable). What you actually >want is to have a group of color cells that have all but four bits >equal, then those four bits give you the sixteen combinations you want. >The routine to allocate colormap cells this way is XAllocColorCells; >you would want to call it with nplanes=4 and npixels=1. If it's In requesting for read/write cells, should n't one ensure that a PseudoColor/DirectColor visual is available at all , before using AllocColorCells ? Probably too important to be explicitly mentioned. -- ------------------------------------------------------------------------------- S Ramakrishnan, CS Dept, McBryde Hall, VaTech, Blacksburg, Virg. 24061-0106 { Email : (Internet) : ramakris@bloss.cs.vt.edu } { : (Bitnet) : ramakrish@VTCC1.BITNET }
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/03/91)
>> To do this, you have to allocate read/write cells instead of >> read-only cells (minor wart, but more or less unavoidable). What >> you actually want is to have a group of color cells that have all >> but four bits equal, then those four bits give you the sixteen >> combinations you want. The routine to allocate colormap cells this >> way is XAllocColorCells; you would want to call it with nplanes=4 >> and npixels=1. > In requesting for read/write cells, should n't one ensure that a > PseudoColor/DirectColor visual is available at all , before using > AllocColorCells ? Probably too important to be explicitly mentioned. Well yes. If you want to have any say at all in the way colors are laid out in the colormap, you need a dynamic visual (ie, PseudoColor, DirectColor, or - though useless in this case - GrayScale). If nothing but static visuals are avaiable, the original problem is either trivial or impossible, depending on whether the colormap has the colors laid out as you want them or not. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
ratnam@lisboa.ks.uiuc.EDU (04/04/91)
Having created a colormap with read/write color cells in a PseudoColor visual class, I find that it is necessary to call both SetWindowColormap and InstallColormap. (This is on SGI with X release 4). I was under the impression that a SetWindowColormap is adequate in Rel.4 and the client does not need to install (or uninstall) colormaps. Can someone clarify? ratnam "Our political experiment of democracy, the last refuge of cheap misgovernment" G.B.Shaw 'Man and Superman'
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/04/91)
> Having created a colormap with read/write color cells in a > PseudoColor visual class, I find that it is necessary to call both > SetWindowColormap and InstallColormap. Then your window manager is broken. > (This is on SGI with X release 4). What window manager are you using? Whatever it is, it's not dealing with window colormaps in the correct ICCCM way, if the SetWindowColormap isn't sufficient. If you've set the window's colormap, a compliant window manager will do the install for you when its colormap focus policy calls for that window to be displayed in its true colors. > I was under the impression that a SetWindowColormap is adequate in > Rel.4 and the client does not need to install (or uninstall) > colormaps. It is supposed to be so. If your window manager is not ICCCM-compliant, you may have to resort to non-ICCCM kludges (like calling XInstallColormap yourself) to get around the problem. Ideally, of course, you should fix the window manager, or switch to another one that *is* compliant. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu