On 2010-09-28 16:24-0400 Hezekiah M. Carty wrote: > On Tue, Sep 28, 2010 at 2:03 PM, Alan W. Irwin > <ir...@beluga.phys.uvic.ca> wrote: >> To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag >> and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array >> with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt >> flag is set, _all_ color indices are interpreted as PLFLT cmap1 values >> in the range from 0. to 1., but otherwise they are interpreted as >> PLINT cmap0 index values. >> > > This sounds reasonable to me. It would be nice to be able to mix and > match cmap0 and cmap1 in the same legend - could this be done with a > per-entry flag? > In this case, each entry's color would be interpreted > according to the matching flag. A possible exception would be the > text color for legend entries - it would probably be a good idea to > leave them as cmap0 (PLINT) only.
After thinking about this some more I have changed my mind, and I now feel strongly that simplest is best so we should just use cmap0 colors for all the various kinds of colors. After all, this is just a discrete legend API so it would be natural to use discrete colors with it. As soon as you add the choice of cmap1 colors for the extreme minority of our users that use them in discrete situations, then the API possibilities start to proliferate like mad with extra arguments required to determine separate cmap0 or cmap1 choices for bg_color, text_colors, line_colors, symbol_colors, and block_colors. To make things worse, the latter four of those are per entry. In sum, I just don't think all those API complications are worth it in order to support what I feel is always going to be an extreme minority use case. > >> One potential downside to having cmap0 and cmap1 alternatives for all >> colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 >> arguments such as the current PLINT *cmap0_colors, PLFLT * >> cmap1_colors arguments. Could we just use generic pointer (void *) >> arguments to stand in for either kind of cmap index/value to halve the >> number of color arguments? I have very little experience with using >> void *, so if you think this idea would work, could you illustrate what to >> do with a commit that replaces the current PLINT >> *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer >> argument? Then I could propagate that idea to all our other color >> arguments, e.g., bg_color, text_colors, line_colors, symbol_colors >> (which are currently restricted to just cmap0). >> > > The simplest option I see is to make all of the color arguments PLFLT. > This would require a user of the C API to copy their cmap0 PLINT > array to a PLFLT array, but it limits the number of arguments. I guess that is the best option if we are going to deal with cmap1 at all, but the downside is it will confuse users to have two interpretations of their floating point numbers depending on a proliferation of cmap0/cmap1 choice options in the API. Thus, as I said above, I now want to keep this simple and stick with cmap0 alone. >> Whatever we decide to do here, I think we should be consistent. So if >> you don't think it is a good idea to provide both cmap0 and cmap1 >> alternatives for all colour arguments (through generic pointers), then >> I think we should probably consistently use cmap0 arguments for all >> colors, i.e., drop the PLFLT * cmap1_colors argument and replace the >> current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with >> PL_LEGEND_DISCRETE_COLOR. >> > > Sticking with cmap0 as the only option is certainly the simplest > approach. For the "simplest is best" reasons above, I am going to drop cmap1 from pllegend. I will try to finish that by late this afternoon. > > I can likely provide more feedback and assistance later this evening, > but I hope these initial thoughts are helpful. Very much so. They brought to my attention some of the complications inherent to catering to cmap1 usage in discrete color situations so I think we are going to have a simpler and therefore better pllegend API as a result. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
