Re: ABI rules on accessing colormap->colors?

["Pawel S. Veselov" <Pawel Veselov Sun COM>]

Hello,

On Mon, Sep 15, 2003 at 07:51:58AM -0400, Owen Taylor wrote:
> On Mon, 2003-09-15 at 06:51, Peter Zelezny wrote:
> > On Mon, 15 Sep 2003 06:21:21 -0400
> > Owen Taylor <otaylor redhat com> wrote:
> >
> > > Well, cmap->colors is going to have correct values for static color
> > > and grayscale as well as pseudocolor .... so checking ->colors != NULL
> > > is probably the most general thing to do.
> > >
> > > But why not just use gdk_colormap_query_color() and let GTK+ worry
> > > about this?
> >
> > Well, I'm trying to find a color inside the colormap that's as close as
> > possible to the R,G,B I actually want. I don't have the exact pixel value.
> >
> > Basically, I'm doing a:
> >      gdk_colormap_alloc_color (cmap, color, TRUE, TRUE);
> > But on a most 8-bit PseudoColor displays, it fails, since the cmap is often
> > full. So I fall back to traversing the cmap->colors to see which is the
> > closest colour available. It gives pretty good results.
> >
> > I tried calling gdk_colormap_alloc_color() with the "best_match" arg TRUE,
> > hoping this would be done for me, but it is not.
> Well, why don't you debug that? If you're right and there is a bug
> there, then we can discuss workarounds, once we know what that bug is.

Hmm, in the example above, both writable and betsmatch are TRUE. If the
writable color is being allocated, bestmatch doesn't make sense, since for
RW color, allocation must succeed, and the cell returned is exclusive.

Peter, have you tried allocating RO colorcells ?

-- Pawel.