Xref: utzoo comp.graphics:3490 comp.windows.x:5814
Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!ames!mailrus!umich!spline.eecs.umich.edu!spencer
From: spencer@spline.eecs.umich.edu (Spencer W. Thomas)
Newsgroups: comp.graphics,comp.windows.x
Subject: Re: getX11 and Utah Raster Toolkit
Keywords: latest version???
Message-ID: <1285@zippy.eecs.umich.edu>
Date: 31 Oct 88 17:43:35 GMT
Article-I.D.: zippy.1285
References: <26075@tut.cis.ohio-state.edu>
Sender: news@zippy.eecs.umich.edu
Reply-To: spencer@spline.eecs.umich.edu (Spencer W. Thomas)
Organization: University of Michigan EECS Dept. Ann Arbor
Lines: 20
UUCP-Path: umich!crimspline!spencer

In article <26075@tut.cis.ohio-state.edu> sarrel@cube.UUCP () writes:
(in reference to a particular X11 program)
>It messes with the color table
>(usually turning the rest of the screen red, sometimes permanently)
>when it really doesn't have to.

This comment leads nicely into one of my current peeves with X11.  I
cannot find any way to get a "default colormap" for any visual other
than the default visual.  Thus, if you are drawing to another visual,
and you want any control over the colors, you MUST create your own
colormap.  This means that independent programs drawing to a visual
cannot share any colormap entries.  Is this really true?  Is there any
way to fix this?

The program referred to above always creates its own colormap because
of this problem, even when the selected visual IS the default visual.
This is clearly less-than-optimal behavior, the program could be fixed
to only allocate a colormap when using a non-default visual.  However,
the anti-social behavior would remain in this case.

=Spencer (spencer@crim.eecs.umich.edu)