Re: One chance to allocate XColormap color, why?

[bleydorf]

Ken Cline wrote:
> 
> Hi all,
> 
> I was trying to create a gradient of 100 colors but kept
> having a problem that some of the middle color values could
> not be allocated.  My solution is just go onto the next
> color up the gradient, however, the XColormap only gives you
> one chance to assign a valid (non white) color for a
> particular value.
> 
> For example, suppose you had:
> 
>       for ( i = 40, c = 0; i < 256 && c < 100; i++ )
>          if ( [ aColorMap setColor: c
>                              ToRed: i
>                              Green: i - 20
>                               Blue: i - 40 ] ) {
>             c++;
>             printf( "Color %d allocated.\n" );
>          }
>          else {
>             c++;
>             printf( "Color %d not allocated.\n" );
>          }
> 
> Then, if for some reason you could not allocate colors
> c = 50, c = 51, and c = 52 then you'd have a "white gap" in
> the middle of the gradient.
> 
> My question is why this limitation was put into the
> XColormap class?  Is it okay to remove the constraint?
> 
> I've added a `unSetColor: (Color) c' method to get around
> this this problem.  So in the code above, I would have:
> 
>          ...
>          else {
>             [ aColorMap unSetColor: c ];
>             printf( "Color %d not allocated.\n" );
>          }
> 
> Whatca think?

My .02,
I thought that colors had to be built with numbers between 0.0 and 1.0?
Could this be the problem?
I'd love to think I could help you Ken...

Brad.

ps.  When is that Java stuff going to released?  Should we be learning
Java?

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================